Address extension accessibility and specificity #4058
Conversation
Makes extension imported by part files be accessible inside the part file, not to the entire library. (Existing phrasing didn't need to distinguish the two.) Makes closer imports in the parent-file chain be more specific than further away imports. This ensures that a part file that imports all its own dependencies, including implicitly referenced extensions, can ignore parent imports and the extensions those parent imports make accessible, and not risk a conflict or override by an equally or more specific extension.
There was a problem hiding this comment.
I have vague misgivings about the complexity of this. In general, it seems like when we allow "shadowing-like" behavior and try to resolve it with some prioritized choice, we often end up with something that feels brittle and confusing.
But the motivation here seems reasonable to me, so it's probably fine.
| > not mentioning the name. | ||
| > In that case the extension is accessible with priority 1. | ||
| > _This includes non-deferred imports with a prefix, and even an unnamed | ||
| > prefix using the the "wildcard variable" unnamed variable notation |
| > with priority *n + 1*. _(Lower is better.)_ | ||
|
|
||
| The "priority *n*" of an extension for a particular Dart file is a measure | ||
| of how far up in the parent chain the import for that extension occurred. |
There was a problem hiding this comment.
Maybe: "parent" -> "part of"?
| > * If *E1* is accessible with priority *n1* > 0 and *E2* is accessible | ||
| > with priority *n2* > 0 _(so both accessible by import)_ then | ||
| > * if *n1* < *n2* then *E1* is more specific than *E2*, and | ||
| > * if *n2* < *n1* then *E1* is *not* more specific than *E2*. |
There was a problem hiding this comment.
Is there a reason this is phrased as "E1 is not more specific than E2" instead of saying "E2 is more specific than E1"?
It reads to me like you're trying to define a partial order, but I don't quite see why when n2 < n1 in this clause. I might be missing some context.
There was a problem hiding this comment.
It is a partial order. And even more, this text is part of a partial order specification.
There can be distinct extensions where neither is more specific than the other. If they are in the set of applicable extensions, then lookup fails.
Saying that E2 is more specific than E1 would not answer whether E1 is more specific than E2 or not.
That would be assuming that the relation is anti-symmetric. (It probably is, but that's a consequence of the definition deliberately avoiding any mutual more-specific relations, and this rule is part of making that so, so it can't also assume it.)
The relation being defined is "E1 more specific than E2" which should give an answer of true or false.
The items are in priority order, and this item gives an answer of "yes" in one case and "no" in another, and otherwise it falls through to the next item (hence "part of a partial order").
Answering any other question doesn't help. (But the rules do imply that if E1 is not more specific than E2 for this reason, then E2 is more specific than E1, since it's the same n values.)
Fix typos
|
Did not do it this way. |
Makes extension imported by part files be accessible inside the part file, not to the entire library. (Existing phrasing didn't need to distinguish the two.)
Makes closer imports in the parent-file chain be more specific than further away imports.
This ensures that a part file that imports all its own dependencies, including implicitly referenced extensions, can ignore parent imports and the extensions those parent imports make accessible, and not risk a conflict or override by an equally or more specific extension.