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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131228/a4d7b284/attachment.html>

On Dec 28, 2013, at 7:38 AM, John Barton wrote:

> I think the differences should include to making calls to super() illegal when 'extends' is absent:
>
> ```js
> 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.