-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Generics details 2: adapters, associated types, parameterized interfaces #731
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Handful of style nits, one place where you could clarify.
I have updated this proposal to reflect the decision made in #739. |
Co-authored-by: Wolff Dobson <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've only reviewed the first ~half of this for now, more to follow.
Co-authored-by: Richard Smith <[email protected]>
Co-authored-by: Richard Smith <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'm very happy with this. I'd like confirmation from the other leads that we're OK with adapter B extends A
being permitted even when A
is final but that's my only blocking concern.
impl as Printable { ... } | ||
} | ||
|
||
adapter SongByArtist extends Song { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. I think this would be useful to explicitly call out. I've made a suggestion below but feel free to ignore it and substitute your own.
Co-authored-by: Richard Smith <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're happy allowing adapter B for A
even if A
is final. Filed #813 to analyze this question further, but we don't need to block on it.
…ces (#731) This proposal goes into the details for these features of generics: - adapters: for creating new types compatible with existing types but with different interface implementations - associated types: allowing an interface implementation to specify some types to use in method signatures - interface parameters: creating a family of interfaces, where types can implement more than one This is a continuation of #553 . It has been summarized in these presentations: - adapters: [1](https://docs.google.com/presentation/d/1bg6q0Q9Sk4YpRbNA3D3H34xYtaEO8ScAUNUZK2UTi80/edit?resourcekey=0-6-Y6e1mfRUmHg-Zk65Gc5A#slide=id.gcf40df1c7b_0_37) and [2](https://docs.google.com/presentation/d/17KG0TeJ4OChMRdLJPS8TE_K6SoL4lFy1FUGr2CDzX-A/edit?resourcekey=0-kLnZqd5NrbGSwmbunTyB-A#slide=id.g7a37009490_0_0) - [associated types and interface parameters](https://docs.google.com/presentation/d/19hPpUjxQ0H1lUSLy5QjS2910Cpc7UdNKpF580fFsCGw/edit?resourcekey=0-ky9XGRC1I8X0Ffw6eqh7WQ#slide=id.p) Co-authored-by: Wolff Dobson <[email protected]> Co-authored-by: Richard Smith <[email protected]>
This proposal goes into the details for these features of generics:
This is a continuation of #553 . It has been summarized in these presentations: