Split augmentations into improved part files and augmentation declara… #3800
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
davidmorgan
added
the
static-metaprogramming
|
Whoops, I thought this was an issue; it's a PR. Opened #3848 so we have an issue for this. |
davidmorgan
removed
the
static-metaprogramming
jakemac53
reviewed
May 29, 2024
jakemac53
reviewed
May 30, 2024
jakemac53
reviewed
Jun 21, 2024
jakemac53
approved these changes
Jun 21, 2024
jakemac53
reviewed
Jun 27, 2024
lrhn
commented
Jun 28, 2024
…tions.
Unifies "augmentation libraries" and part files.
Part files can have imports, exports and further part files.
Part files can use configurable URIs.
A `part of` directive can no longer use a library name.
Part files inherit the imports of their parent file, and can
extend or shadow those with their own imports.
Augmentation declarations can occur in any part or library file.
An augmentation must occur "below" the declaration it augments:
Either later in the same file ("below" when viewing code),
or in the file-tree of a part file of the same file ("below" in
the part-file tree of the library).
This ensures that the original declaration occurs above all
augmentations of it, and that all augmentations of the same
original declaration occur on a single path down the part-file tree
of the library. What again ensures that reordering `part` directives
does not change the order of augmentations.
Changed the lexical scope of augmenting class-like declarations
(declarations with a member scope) to only contain the members
declared inside the same class-like declaration, not the collection
of all members declared by all declarations with the same name.
Rewrote the part about applying augmentations. This is more
speculative since it doesn't provide a complete definition,
but more of a pattern for extending semantics that assume a
name refers to a single declaration, into one where a name
denotes a set (stack depending on augmentation application order),
of individual syntactic declarations.
The existing semi-syntactic "merging" may not be a viable
specification approach, since it requires merging code
from different scopes into a single scope. That's not impossible,
we also move code around for mixin applications, but it's also
easy to get wrong.
lrhn
force-pushed
the
augment-spec-update
branch
from
9ed33c1
to
bf5fc86
Compare
scheglov
reviewed
Aug 5, 2024
| chooses the URI that the `part` directive refers to, and after that the | ||
| included file works just as any other part file. | ||
|
|
||
| It’s a **compile-time error** if a Dart (parent) file with URI *P* has a `part` |
There was a problem hiding this comment.
When I read this paragraph, it seems that there are a few typos.
"does not parse as a <partDirective>" - maybe < partDeclaration >?
"does not denote the library of P" - we can have partDirectives not only in libraries, so maybe "the file with URI P"?
There was a problem hiding this comment.
ACK, <partDeclaration> for the entire part file, <partDirective> for the part "..."; directive.
And yes, "the file P" is correct. (Damn! I hoped I had found all of the places that assumed a parent file was a library.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…tions.
Unifies "augmentation libraries" and part files.
Part files can have imports, exports and further part files. Part files can use configurable URIs.
A
part ofdirective can no longer use a library name. Part files inherit the imports of their parent file, and can extend or shadow those with their own imports.Augmentation declarations can occur in any part or library file. An augmentation must occur "below" the declaration it augments: Either later in the same file ("below" when viewing code), or in the file-tree of a part file of the same file ("below" in the part-file tree of the library).
This ensures that the original declaration occurs above all augmentations of it, and that all augmentations of the same original declaration occur on a single path down the part-file tree of the library. What again ensures that reordering
partdirectives does not change the order of augmentations.Changed the lexical scope of augmenting class-like declarations (declarations with a member scope) to only contain the members declared inside the same class-like declaration, not the collection of all members declared by all declarations with the same name.
Rewrote the part about applying augmentations. This is more speculative since it doesn't provide a complete definition, but more of a pattern for extending semantics that assume a name refers to a single declaration, into one where a name denotes a set (stack depending on augmentation application order), of individual syntactic declarations.
The existing semi-syntactic "merging" may not be a viable specification approach, since it requires merging code from different scopes into a single scope. That's not impossible, we also move code around for mixin applications, but it's also easy to get wrong.