Will any new features be tied to constructors?
allen at wirfs-brock.com
Tue Jun 30 15:54:36 UTC 2015
On Jun 29, 2015, at 11:29 AM, Anne van Kesteren wrote:
> On Sat, Jun 27, 2015 at 2:21 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> For custom elements in DOM there's a proposal to have the constructor
>> be controlled by the user agent and have some kind of callback that
>> actually initiates the element. This has some advantage in that it
>> allows the script to load lazily while the parser continues running.
>> However, if the user agent always invokes the constructor, would that
>> exclude us from new features? E.g. I could imagine private data
>> properties to be an allocation affair of sorts.
>> (Note: I'm not personally pushing this design, I'm just exploring the
> To clarify, since this was not completely clear, the question is
> whether anything other than object allocation will be allowed only
> have plans to restrict certain object functionality to constructors,
> or will constructors only ever be responsible for object allocation
> and nothing else?
> The answer to this question would greatly impact the way we make DOM
> extensible. And given that we plan to decide on that in three weeks
> time any quick answer would be appreciated. Thanks!
TC39 hasn't yet agreed upon a design for adding "private state" to user defined ES6 objects, but at least one plausible design would model such state very similarly to how "internal slots" are handled in ES6, including that the final internal state "shape" of an object must be determined by the time it is allocated. In this regard, it seems that a custom element might frequently want to make use of such private state if it was available.
How would your hypothetical early allocated objects be observably exposed? If ES code has access to an object in such a state, what could the code reasonably expect to do with it? For example, if the script that defines the specific custom element class has not been loaded then the neither the [[Prototype]] or any of the prototype properties of the custom element instance would be known or available.
In the general case, what you are asking for seems to be roughly equivalent to a "becomes" operation. Are you essentially trying to obtain early access to the identity of the custom element? If no operations (other than ===) are allowed prior to final allocation, then I can imagine some sort of more specialized deferred allocation that would give you early identity access without the full compleity of "becomes".
But is it even necessary to preserve identity? After all, scripts can dynamically add and remove DOM elements at any time. So it seems that there really isn't any guarantee that the identity of DOM elements aren't dynamically changing.
What's wrong with inserting a "deferred custom element" node into the DOM when you initially parse and then replacing it with an actual custom element instance of the correct class when when the script it depends upon has been loaded?
More information about the es-discuss