On May 30, 2012, at 5:31 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> Ultimately, I think we will find that we can't have a semantics like|super|  
>> that is only usable within a syntactic class definition but has no 
>> reflective support and no way way to programmatically desugar a class 
>> definition into  the exact equivalent set of object definitions.
> 
> That's not so, and at last week's meeting, we discussed alternatives 
> including gensym'ed lexical bindings used by a less local transformation-spec.

Sorry, I didn't mean a mechanical de-sugaring that produces into a logically 
equivalent semantics using different lower level construct.  I mean a 
refactoring of the exact same function bodies into more primitive ES 
object/function definitions.  For example:

class Foo extend Bar {
   constructor (z) {
       this.z
   }
  method m1 ( ) {
     return this.z
  }
  method m2 () {
     return this.m2()
  }
}

as being equivalent to 

let Foo = function Foo(z) {
       this.z
   }
Foo.__proto__ = Bar;
Foo.prototype= {
  method m1 ( ) {
     return this.z
  },
  method m2 () {
     return this.m2()
  }
}
Object.defineOwnProperty(Foo.prototype,"constructor",{value: Foo,});
Foo.prototype.__proto__ = Bar.prototype;

This equivalence breaks down if you can't have super in any of the method 
bodies.  You can try to create an equivalent semantics but by rewriting parts 
of the bodies but it probably won't be perfect (dealing with __proto__ changes 
on the prototype object seems difficult).  

 
> 
>>   That's only half a solution.
> 
> This ignores the *cost* of letting super be written in any function, which we 
> definitely discussed. Many on TC39 are concerned this is a footgun. Anyone 
> writing super in a function may bind to the wrong object (e.g., the 
> dictionary-parameter object containing the function-valued property, passed 
> into an API but itself not used after the call -- see Kevin Smith's mail from 
> a past thread this year).
> 
> We talked about all of this and more than a few people in the room objected 
> to allowing people to write "wrong-super" (like "wrong-this" only even less 
> useful) functions and then tell developers facing bugs to "use 
> Object.defineMethod".

I agree, Object.defineMethod is a foot gun.  I don't don't agree obj.{method() 
{super()} } seems like a much safer way to express the samething.

> 
>>   support of|super|  outside of class is the only think missing to enable 
>> that.
> 
> No, there are alternatives that confine super to be usable only within 
> classes.

yes, but with the loss of decomposability as outlined above. 

> 
>>  So, it something I will likely continue top push on.
> 
> If the committee or significant (more than two) members are against the 
> approach, this is not productive.

Yes, its all about finding consensus.

But, if you don't play you can't win...

Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to