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.

Sign up for GitHub

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

Jump to bottom

Clarify extension member resolution #4116

Merged
merged 3 commits into from
Oct 2, 2024
Merged

Clarify extension member resolution #4116

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3919306
Clarify extension member resolution
eernstg Oct 1, 2024
3ac715c
WIP
eernstg Oct 1, 2024
8c4c95b
WIP
eernstg Oct 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 6 additions & 1 deletion specification/dartLangSpec.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,11 @@
% version of the language which will actually be specified by the next stable
% release of this document.
%
% Sep 2024
% - Clarify the extension applicability rule to explicitly state that it
% is concerned with an instance member with the same basename, not a
% static member.
%
% Jun 2024
% - Add missing references to section 'Type dynamic' at the points where the
% static analysis of Object member invocations is specified.
Expand Down Expand Up @@ -6661,7 +6666,7 @@ \subsubsection{Applicability of an Extension}
because they do not have a type.%
}
\item
The type $S$ does not have a member with the basename $m$,
The type $S$ does not have an instance member with the basename $m$,
Copy link
Member

@lrhn lrhn Oct 1, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

Do we have a name for "the set of instance members of a type"? I sometimes use "type interface" or "type member signatures".
It's the signatures of the members that a typed member access/invocation can access on a receiver with that type as static type.
(Because that's the kind of members this text is talking about. Not declarations, not concrete "instance members", just the things that can be accessed on something with that static type.)

Copy link
Member Author

Choose a reason for hiding this comment

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

We do use "members of" a library, class, mixin, or enumerated type, "instance members of" a class or extension, "static members of" a class or extension, "a member of" the type void, a super-bounded type, the on-type, "members for" a type, "a member of" an object.

Another branch of this terminology may be better in general: We're quite frequently talking about "the interface of" an interface type, which is considered to be a nominally identified set of member signatures.

So we do certainly talk about the members of a class or class-like entity, explicitly mentioning both of the static and instance kinds. We do also talk about the members of a type (not nearly as many times), again both kinds.

But I think it's fair to say that the elements in the interface of an interface type would be instance members, implicitly or explicitly.

I think we're OK using 'static members of a class' and 'instance members of a class', no problem, and we're pretty much OK using 'static members of an interface type' and 'instance members of an interface type', even though those occurrences should perhaps be modified to talk about the underlying class/mixin/whatever that was used to induce said type.

And I think it's fair to say that the interface of an interface type contains only instance members. We could still include the word 'instance' to double down on the disambiguation.

Copy link
Member

Choose a reason for hiding this comment

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

Indeed. The issue here is that the on type of an extension may not be an interface type, and yet I want to talk about the interface of it, meaning the set of member signatures that it has. (Which includes the "members of Object", for function types an instance method names call, for record types instance getters for each field, and for extension types, the extension members of the type.

If we could consistently say "the type signature of at type" to mean that set of member signatures, then that could make some things much easier to talk about. (And the type interface/signature of an interface type is the interface type's interface members, unsurprisingly.)

(I've considered "type interface" and "type signature", but I like "signature" better because it matches "member signature", which is itself a useful abstraction over something with a name and a way to use it - getter, setter, or method so far.)

Copy link
Member Author

Choose a reason for hiding this comment

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

If we could consistently say "the type signature of at type" to mean that set of member signatures

I've used "the interface of a type" with that intended meaning many times. The specification does say "interface type" in a number of situations, but I don't see a problem with a slightly more forgiving use of this phrase that includes some non-interface types with the Object members as the interface. Record types is a good example, they certainly do have getters named in ways like $1 and $foo, and I don't see why we should special case them in the situation where we just want to talk about the available static information about instance members.

and $S$ is neither \DYNAMIC{} nor \code{Never}.

\commentary{%
Expand Down