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 <[email protected]> >> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
