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.
Maybe we should make DOM constructors behave sort of like the Array constructor, of course...
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.
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.
All this doesn't affect subclassing of things like Date, of course. -Boris _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
