domenic at domenicdenicola.com (2014-06-20T19:44:27.770Z)
On 6/13/14, 2:20 PM, Allen Wirfs-Brock wrote:
> The default @@create is approximately:
>
> ```js
> Function.prototype[Symbol.create] = function(I) {
> return Object.create(this.prototype)
> }
> ```
Ah, I see. So the point is in normal use @@create is passed the right
prototype to start with implicitly, via "this".
Doing that for @@create in the DOM might not be very backwards
compatible, but we could probably do something like use the canonical
prototype if "this" is the canonical constructor and else do this.prototype.
The main remaining issue with @@create is making all the DOM specs
handle a created but not initialized object or something... That's
something I'd been hoping to avoid, since it requires wholesale changes
to a bunch of specifications, not all of which are even actively edited.
:( I suppose we could make things subclassable on an opt-on basis or
something to work around that.
On 6/13/14, 2:20 PM, Allen Wirfs-Brock wrote: > The default @@create is approximately: > > Function.prototype[Symbol.create] = function(I) { > return Object.create(this.prototype) > } Ah, I see. So the point is in normal use @@create is passed the right prototype to start with implicitly, via "this". Doing that for @@create in the DOM might not be very backwards compatible, but we could probably do something like use the canonical prototype if "this" is the canonical constructor and else do this.prototype. The main remaining issue with @@create is making all the DOM specs handle a created but not initialized object or something... That's something I'd been hoping to avoid, since it requires wholesale changes to a bunch of specifications, not all of which are even actively edited. :( I suppose we could make things subclassable on an opt-on basis or something to work around that. -Boris