Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address extension accessibility and specificity #4058

Closed
wants to merge 2 commits into from

Conversation

lrhn
Copy link
Member

@lrhn lrhn commented Aug 26, 2024

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.

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.
Copy link
Member

@munificent munificent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: "the the" -> "the".

> 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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*.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

@lrhn
Copy link
Member Author

lrhn commented Oct 7, 2024

Did not do it this way.

@lrhn lrhn closed this Oct 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants