ES6 classes: deferring the creation step

Boris Zbarsky bzbarsky at MIT.EDU
Wed Jul 2 14:51:15 PDT 2014

>> Le 27 juin 2014 à 15:56, Claude Pache<claude.pache at>  a écrit :
>>> Here is a counter-proposal (or an improved
>>> proposal, ad libidum), which is not tightly coupled to @@new.

This proposal seems ok to me from my DOM-centric perspective.  ;)

>>> Optional: the @@create hook
>>> ----------------------------
>>> A @@create hook can easily be placed as follows:
>>> In each [[Call]] internal methods defined above, a call to
>>> (`thisArgument`.[[Constructor]]).@@create
>>> could replace the steps spanning from
>>> GetPrototypeFromConstructor(...) inclusive to
>>> InitializeThisBindings(...) exclusive.
>>> Whether such a hook is compatible with, e.g., DOM constructors, is
>>> left to the appreciation of the competent people. At worst, a
>>> built-in constructor could cheat by defining its own [[Call]]
>>> internal method that would refuse to run the @@create hook.

The problem with @@create is not so much whether built-in constructors 
call it.  It's whether user code can invoke built-in @@create hooks and 
hence observe partially-constructed object.

However, with this proposal it seems easy enough to just not provide any 
such built-in @@create hooks, right?


More information about the es-discuss mailing list