-
Notifications
You must be signed in to change notification settings - Fork 159
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
Adding slots [initial braindump] #258
Comments
Prior discussion: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27354. Given that we don't have a unified type system we should probably not block slots on that. So an initial version would not have explicit types (all done through prose). It does seem good to define slots for an interface in a formalized way and have syntax for getting at them. We'll need to allow for mixins/partial too. Having a way to address "this" should probably come first. Being able to do "this.[[slot]]" would be enormously helpful. I suspect defining slots in IDL would be the most natural as you need to know about them when putting together an object. If we want to go for brevity, I think there's something to be looked at around IDL attributes. While not all of them would need a backing slot (e.g., |
I'm not really convinced that IDL syntax is particularly valuable (though perhaps I'm wrong on that); I'm thinking more in the direction of a table with columns name/type/non-normative short description. |
Thing is, you need association with interface/mixin/partial to be pretty explicit. And the linked bug has some ideas for how we could eventually automate associated object creation through this setup. We can also define attribute getters/setters near automatically if they are associated through IDL. Lots of value there I think long term. |
As I expressed in IRC, I think slots should not have types. We could informally say that Web IDL types, infra types and structures, and flags are what we typically expect in there, but we shouldn't annotate them formally. This means we don't need to make rules around coercion or type unions, I believe.
I'm not sure, personally.
I'd go with just
In general an object is allocated with all the slots of its "main interface", any interfaces that one derives from, and any partial interfaces that extend anything in that chain, and any mixins mixed into anything in that chain. I bet there is a term already defined in Web IDL for this collection of interfaces.
If there is no type system this should be fairly clear. Overall, I'm not sure this adds much value by itself, as @Ms2ger says. I guess it gives some standardized format for documentation of what internal slots an object already has, and notation for using them, and maybe encourages people to start using them as a concept, if they weren't before. Maybe that's enough. But to really get benefits, I think you need something that auto-associates certain attributes with slots, as discussed in Bugzilla. |
We actually need the link with IDL attributes if we ever want to define Event interfaces properly. Otherwise defining a generic constructor is impossible. |
One more thought: do we want non-IDL types like environment settings objects to have slots as well? It seems useful to have the same syntax available there. |
Yeah, but that's for Infra Standard to define. |
Strongly agree. Having a syntactic distinction between slots and attributes makes my life (and BS users) a ton easier.
Yeah. In effect, slots are just Symbol-typed attributes, with the Symbols known only to the runtime and not otherwise exposed. They inherit/etc exactly the same as attributes do.
I'd love it if every attribute implicitly had a backing slot, and Bikeshed could just make the definitions/links work. If you have custom get/set behavior (like |
I'll get back to this shortly. |
For reference, in Typed OM I'm just pretending that every attribute has an implicitly defined backing slot, which is used for reading/writing in the obvious way unless I have a special algorithm defined. I would like to amend Bikeshed to auto-define |
I'm also finding myself wanting to have slots in the IDL during testing. Having them in the IDL would give a nicer mental model of what the underlying state machine is for an given interface. |
Proposal here: #495. |
I'd like to tackle adding slots to WebIDL soonish.
After some preliminary discussions in #whatwg on irc, it seems we want to start with a lightweight system and see how that goes first.
What values can slots contain?
It seems slots should be able to indifferently hold WebIDL types, Infra primitive data types and data structures, and flags (boolean thingies that are either set or unset).
Type coercion
We want to avoid type coercion. Editors need to be explicit about what values slots hold and make sure not to rely on type coercion for those.
Should we disallow type unions in slots?
Syntax for defining slots
Should we define slots in WebIDL fragments? e.g.:
If so, what syntax should we use?
Should we include slot type in there? If so, how do we handle infra "types"?
How do we deal with inheritance?
Should we instead consider using tables for slots like the Streams spec does?
Syntax for using slots
We'd want to be able to use slots in specs like we use ES6 ones:
Bindings
Slots are private so no bindings. Is that worth being explicit about?
Other
This is the first time I tackle adding a large feature to WebIDL, so I'm pretty sure I haven't considered all the things. Comments, thoughts, questions, etc. are most welcome.
The text was updated successfully, but these errors were encountered: