Configured imports

[lrhn]

I have created a proposal for configurable import statements.

Note: This issue exists to track the status of the proposal. If you would like to provide feedback on the proposal itself, please do so on its repo, linked above.

[tatumizer]

Syntax is a bit odd. I think I understand the motivation, but still, normal ternary ?: would look more natural IMO. All the proposed restrictions on what can be and cannot be there will still apply, it's just "?" instead of colon, and colon instead of "||". Kind of "stripped-down ternary conditional"

[bwilkerson]

The proposal states:

An analysis tool, like the Dart Analyzer, can see all possible import strings, and either resolve to a single URI for a given platform/configuration, or examine all the combinations.

This is not true (or at the very least is misleading). The analyzer does not require the values of "environment" variables to be specified. Therefore, it will not, in general, be able to determine which import will be selected, and will be forced to analyze every such library against all possible combinations of imports. This will significantly increase the amount of analysis that needs to be performed, which could have serious performance implications. (Three imports with two options each will result in analyzing the library 8 times. Any library that directly or indirectly imports the library containing the imports will (in the worst case scenario) likewise need to be analyzed 8 times.)

[zoechi]

I would prefer something like

import 'package:somepackage/somelib_[browser|standalone].dart';

where the available/supported options are listed between [...]

[eernstg]

Combinatorial explosions are always unpleasant, but I think it is no
problem to run the analyzer 8 times if it does 8 different jobs.

But we could have a large number of combinations and a system structure
where naively enumerating all the combinations involves a massive amount of
identical subtasks. In principle, this is similar to analyzing many
separate software systems ("programs") with a substantial amount of shared
libraries (i.e., libraries that are imported by many of them).

Considering the former as a special case of the latter, you could say that
it would be great to minimize the redundant work, but even the naive
starting point isn't worse than the situation we have today (where those
configurable imports would be emulated using multiple source files), and
there is a good potential for improvement.

Another matter is that it might be useful during development to be able to
specify a given environment for the analyzer, such that it puts the focus
on just one (or a few) "relevant" combinations, e.g., in order to allow for
parallel development with respect to several platforms.

On Thu, Mar 5, 2015 at 6:18 AM, Brian Wilkerson [email protected]
wrote:

The proposal states:

An analysis tool, like the Dart Analyzer, can see all possible import
strings, and either resolve to a single URI for a given
platform/configuration, or examine all the combinations.

This is not true (or at the very least is misleading). The analyzer does
not require the values of "environment" variables to be specified.
Therefore, it will not, in general, be able to determine which import will
be selected, and will be forced to analyze every such library against all
possible combinations of imports. This will significantly increase the
amount of analysis that needs to be performed, which could have serious
performance implications. (Three imports with two options each will result
in analyzing the library 8 times. Any library that directly or indirectly
imports the library containing the imports will (in the worst case
scenario) likewise need to be analyzed 8 times.)

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

Erik Ernst - Google Danmark ApS
Skt Petri Passage 5, 2 sal, 1165 København K, Denmark
CVR no. 28866984

[jmesserly]

fyi, some of these comments might be good as issues over at https://github.com/lrhn/dep-configured-imports/issues ... I went ahead and filed lrhn/dep-configured-imports#4 for the analyzer issue

[bwilkerson]

Erik, Please see my response in the issue John opened.

[munificent]

Hey, @tatumizer and @zoechi, can you file your feedback as separate issues on the repo for the proposal? This issue is just for tracking the proposal's status. Thanks!

[munificent]

It's been a while since this DEP was updated! As you probably know, we're moving ahead on interface libraries (#40), so I'm closing this alternate approach.