Will any new features be tied to constructors?

[Boris Zbarsky]

On 7/1/15 11:12 AM, Domenic Denicola wrote:
> Right now the UA allocators for all elements contains a single private slot, a pointer to the backing C++ object.

Just as a note, this is true conceptually in the specifications but 
happens to not be true as a matter of implementation reality in either 
Gecko or (planned? not sure where they are with their fused allocation 
setup) Servo.  There can be various numbers of preallocated private 
slots in practice.

The UA allocators for elements contain some UA-determined set of private 
slots would be a better way of putting it.

> Private state is, of course, stored in the backing C++ object.

This is, again, not true for Gecko.  Some private state is stored in the 
backing C++ object.  Some (e.g. the backing Map for an IDL maplike) is 
stored directly in a private slot of the JS object.  This is a matter of 
implementation convenience, of course; no spec defines where these 
things should be stored; it just happened to be easier to do the GC bits 
this way.

> Maybe some implementers can correct, but I doubt retrofitting this structure to support additional arbitrary author-defined private slots, introduced at any level in the hierarchy, is at all insignificant.

I can't speak to the difficulties of doing or not doing this in 
SpiderMonkey without us having implemented this.  However, I suspect 
that whatever setup normal Object ends up using here in SpiderMonkey 
would also be usable by DOM objects...

I obviously can't speak for other implementations.

-Boris