Re: [heycam/webidl] [wip] First pass at adding internal slots (#495)

1. We need a way to disable slot generation, e.g., for `innerHTML`. It's probably not acceptable that it would generate an unused slot. It's unclean and implementations would end up adding proprietary syntax for it. I suggested `[NoSlot]` in the original bug.
2. When I look in DOM for "has an associated" it seems default values of

   * null
   * the empty string
   * string constants, e.g., "no-quirks"
   * false (for initially unset flags we'd convert to booleans)

   would see quite some use. There's also a couple cases where it cannot be used though, such as URLs, empty sets, empty lists, and MIME types. It might be confusing to have some in IDL and some in prose. (Maybe if we ever have a more unified type system it'd be more doable.)
3. I agree with having all slots in IDL interfaces. If we also want concept-level slots we should add those to Infra, but I think we can continue to use simple prose for those.
4. As for "this", an idea I had at some point is that IDL effectively generates the same of the algorithm that the specification needs to define. Say `ElementNamespaceURIGetter`. And then it invokes that algorithm name it generated with a reference to the object itself as the first argument and the remaining arguments as subsequent arguments. I still think that'd be great as it fully closes the formalization gap, but I realize it's quite a bit of work to get done.

   Another benefit of this is that we clearly separate the internal and public endpoints and now by default have an internal algorithm to call for each algorithm we may want to reuse somewhere.

   Probably the most pragmatic step is to just define a magic keyword as you did, unless there's more enthusiasm for my idea.

-- 
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/pull/495#issuecomment-351390889