Will any new features be tied to constructors?

[Domenic Denicola]

Thanks for the corrections Boris. I was basing what I said on a half-remembered version of https://ask.mozilla.org/question/850/how-do-webidl-methodsgetterssetters-tell-whether-objects-are-of-the-right-types/, but upon re-reading that I see that I missed the "at least" in "at least one reserved slot", and made a few other unwarranted assumptions along the way.

My apologies to Allen and everyone else for misleading assertions.

-----Original Message-----
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Boris Zbarsky
Sent: Thursday, July 2, 2015 00:35
To: es-discuss at mozilla.org
Subject: Re: Will any new features be tied to constructors?

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
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss