Adding slots [initial braindump]

[tobie]

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

interface Animal {
  slot children;
  readonly attribute DOMString name;
  attribute unsigned short age;
};

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:

1.  If object.[[flag]] is unset, then:
    1.  Set object.[[state]] to "errored",
    1.  Etc.

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.

[tobie]

/cc @bzbarsky @domenic @annevk @heycam

[annevk]

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., innerHTML sure doesn't except perhaps for optimization purposes which we don't need to define), a lot of them do. The problem with that is of course that attributes have a type, which we'd need to ignore for the slot and that an attribute line on its own is already getting quite verbose with the various extended attributes we've been adding.

[Ms2ger]

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.

[annevk]

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.

[domenic]

What values can slots contain?

Type coercion

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.

Should we define slots in WebIDL fragments?

I'm not sure, personally.

If so, what syntax should we use?

I'd go with just [[children]]. I think it's important the double brackets appear at declaration time, and when you have those

How do we deal with inheritance?

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.

Slots are private so no bindings. Is that worth being explicit about?

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.

[annevk]

We actually need the link with IDL attributes if we ever want to define Event interfaces properly. Otherwise defining a generic constructor is impossible.

[Ms2ger]

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.

[annevk]

Yeah, but that's for Infra Standard to define.

[tabatkins]

I'd go with just [[children]]. I think it's important the double brackets appear at declaration time,

Strongly agree. Having a syntactic distinction between slots and attributes makes my life (and BS users) a ton easier.

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.

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.

But to really get benefits, I think you need something that auto-associates certain attributes with slots, as discussed in Bugzilla.

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 innerHTML) you might not actually use that implicit slot, and since its presence is otherwise unobservable, implementations can just not generate it.

[tobie]

I'll get back to this shortly.

[tabatkins]

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 [[foo]] for every foo attribute, to reduce the verbosity of some of that spec text.

[marcoscaceres]

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.

[tobie]

Proposal here: #495.