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

> and implementations would end up adding proprietary syntax for it.

I'm not quite sure, as an implementor to what extent I would end up generating slots based on IDL information anyway.

If I'm generating the entire implementation (e.g. this is what Gecko does with a number of Event subclasses), then it makes sense to generate internal slots, of course.  Right now we do this precisely by generating slots for all the attributes.  This only works for cases in which there is nothing interesting going on with the slots other than values being stored in the constructor and then read and maybe set via attributes.

But there are lots of cases in which whether there's a slot is an implementation decision.  Let me give one "simple" example.  `Element` has `tagName` and `localName` attributes.  Per spec, `localName` just does a slot read, while `tagName` runs an algorithm including getting the "qualified name", which it itself an algorithm that reads some slots, includingf the "local name" slot.

In Gecko, all three of "local name", "qualified name", and "tagName" are computed ahead of time and stored on the element.  But they're not really stored in slots on the element itself, in implementation terms.  What's stored in a slot is a pointer to a shared data structure (shared across all elements with the same namespace/prefix/localName in the element's node document) that stores all these bits.  That means we compute them once on a per-document basis (instead of the spec's per-get computation, getters are fast, etc.  This all works because all of this state is immutable.

But nothing requires things to work this way.  A different implementation could make different tradeoffs here in terms of what's stored in slots and what's computed and what's shared and so forth.

-- 
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-351446039