- From: Domenic Denicola <notifications@github.com>
- Date: Mon, 19 Dec 2016 11:24:55 -0800
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/issues/258/268054180@github.com>
> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/issues/258#issuecomment-268054180
Received on Monday, 19 December 2016 19:25:31 UTC