On Feb 18, 2014, at 1:12 PM, Boris Zbarsky wrote: > On 2/18/14 2:51 PM, Allen Wirfs-Brock wrote: >> I'm also a bit concerned, that there may be a meme starting that it will >> be a looooooong time (years, if ever) before @@create is actually >> implemented so JS developers really shouldn't count on being able to use >> it if the foreseeable future. Such a meme could become a self-fullying >> prophecy. > > The longest pole on @@create from my point of view as a DOM implementor is > that the setup for it is not quite compatible with how DOM constructors work > (and have worked for many a year now) in Trident- and Gecko-based browsers. > Specifically, Gecko and Trident allow a DOM constructor without "new" to > create a new object of the right type (in ES5 terms, they're implementing a > special [[Call]], not special [[Construct]], for DOM objects). > > Which means that before we can allow subclassing DOM objects we need to go > through things like a deprecation period, use counters, etc, etc, to ensure > that we're not breaking existing content that relies on the current behavior.
In that case, i don't see why the DOM is a barrier to adding @@create to JS. The normal [[Construct]] behavior to specified to fall back to essentially ES5 behavior if an @@create isn't found. So it sounds to me that the above DOMs would just keep working as is if @@create+new is implemented as specified by ES6. The DOM classes wouldn't be subclassable out of the gate, but new things like Promises would be. > > Maybe we should make DOM constructors behave sort of like the Array > constructor, of course... Do you really think you can deprecate exist call without new instantiation behavior? In ES6 every legacy constructor that had that behavior is specified to still have that behavior and always will. Are you saying that it isn't de-facto standard behavior and so there is a hope of getting rid of it. > > If we don't, then SpiderMonkey implementing @@create in the abstract will > not automatically make the DOM subclassable in Gecko, and the latter cannot > possibly take less than 5-6 months (to fix all the code we know depend on the > current DOM constructor behavior, add telemetry and warnings, get reliable > telemetry results back). That's if we discover that DOM constructors without > "new" are not used in the wild. If they _are_ used, add more time for > figuring out who's using them and convincing them to stop. SpiderMonkey implementing @@create is a prerequisite to making the DOM subclassable. But DOM use of @@create isn't a prerequisite for adding general JS @@create support. > > Of course adding an extra internal slot to all DOM objects is not necessarily > all that great either... Though maybe we have to do that no matter what to > prevent double-initialization. You don't necessary need a new slot to to use as an initialized flag. I most cases you can probably get away with using a "not yet initialized" token in some existing slot. > > All this doesn't affect subclassing of things like Date, of course. Write, we don't have to pre-boiled the ocean in order to start the beach fire... Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
