domenic at domenicdenicola.com (2014-02-05T19:41:59.902Z)
I made the change in rev 22 to make the default constructor: return super(...args)
However that resulted in this bug: https://bugs.ecmascript.org/show_bug.cgi?id=2491 from Arv:
> The problem arises when we extend an old school "class" where the code does not
> explicitly set constructor.
>
> ```js
> function B() {}
> B.prototype = { ... }
> class C extends B {}
> new C() instanceof C // false
> ```
>
> The reason why this fails is that `B.prototype.constructor === Object` so `new
> C()` returns `Object()`.
>
>
> The work around is to set `B.prototype.constructor = B` but I feel like the
> problem, adding return added solved, is smaller than the problem it introduces.
I'm inclined to agree with Arv's conclusion. What do you think?
I made the change in rev 22 to make the default constructor: return super(...args) However that resulted in this bug: https://bugs.ecmascript.org/show_bug.cgi?id=2491 from Arv: > The problem arises when we extend an old school "class" where the code does not > explicitly set constructor. > > function B() {} > B.prototype = { ... } > class C extends B {} > new C() instanceof C // false > > The reason why this fails is that `B.prototype.constructor === Object` so `new > C()` returns `Object()`. > > The work around is to set `B.prototype.constructor = B` but I feel like the > problem, adding return added solved, is smaller than the problem it introduces. I'm inclined to agree with Arv's conclusion. What do you think? Allen On Dec 28, 2013, at 11:11 AM, Allen Wirfs-Brock wrote: > > On Dec 28, 2013, at 7:38 AM, John Barton wrote: > >> >> >> >> On Fri, Dec 27, 2013 at 10:22 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote: >> >> On Dec 27, 2013, at 7:27 AM, Brendan Eich wrote: >> ... >>> I thought Allen designed things so >>> >>> class C {} >>> >>> differed from >>> >>> class C extends Object {} >>> >>> so as in the first case to avoid (a) super calling Object and making a useless newborn; (b) C inheriting class-side properties from Object. >> >> Exactly, see step 7 of http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-classdefinitionevaluation >> >> Allen >> >> >> I think the differences should include to making calls to super() illegal when 'extends' is absent: >> class C { constructor(url) {super(url);}} // legal, I expected illegal. >> > > Plausible, but what about the possibility that a framework dynamically patches the prototype chain of C.prototype before it is first instantiated or if C uses its @@create method to return instances that have different or extra objects (that have a 'constructor' property) patched into their prototype chain. > > This, like the base question of this thread, seems like another example of a tension between supporting the "normal" usage patterns for class declarations and allowing enough flexibility to enable using class declarations as building blocks for less normal abstractions. > > I could probably go either way. Pragmatically, from a spec. writing perspective, the conditions for issuing this error are bit complicated to define. Even without an extends clause the instances still inherit from Object.prototype so super call still need to be allowed in non-constructor instances methods and even in constructor methods things like super.toString() need to be allowed. I generally try to avoid early errors that have a lot of conditions associated with them. > > Allen > > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140202/77a66196/attachment.html>