We would have to have additional internal state to capture the method name 
("constructor" or whatever) but we are already doing something similar to 
capture the super object binding so it isn't inconceivable.  We I look at 
implicit super naming in the past it also appeared to create issues for 
getter/setter property accesses:

  var p = sup <| {get foo() { return super}  //is this the same as return 
super.foo ???
   };  


Allen



On Oct 30, 2011, at 12:54 PM, Axel Rauschmayer wrote:

> But we could have super(foo) as syntactic sugar for super.constructor(foo), 
> right? Not that I think it matters terribly...
> 
> On Oct 30, 2011, at 20:51 , Allen Wirfs-Brock wrote:
> 
>> 
>> On Oct 30, 2011, at 3:36 AM, David Bruant wrote:
>> 
>>>> ...
>>> I wonder if the "only one semicolon" obsession is really worth it. Consider:
>>> -----
>>> const className = superClass <| function(/*constructor parameters */) {
>>>        //constructor body
>>>        super.constructor(/*arguments to super constructor */);
>>>        this.{
>>>         //per instance property definitions
>>>        };
>>>    };
>>> 
>>> className.prototype.{
>>>    // prototype properties
>>> };
>>> 
>>> // and if really necessary:
>>> /*className.{
>>>    // "constructor properties"
>>> };*/
>>> -----
>>> 
>>> As far as I'm concern, this is declarative enough:
>>> 1) <| provides the proper "super" (why the ".constructor"?) within the
>>> constructor body
>> 
>> In general, it is necessary to know at runtime what property name you are 
>> doing a super look up for. the name can be either implicit or explicit but 
>> it has to come from somewhere and generally JS functions don't always have 
>> intrinsic names. Also there are some issues relating to super references to 
>> getter/setter properties that make the explicit name nice.  Also, sometimes 
>> the method you want to super invoke is the name same name as the current 
>> method (for example, see 
>> https://github.com/allenwb/ESnext-experiments/blob/master/ST80collections-exp1.js#L419
>>  ).  We may be able to work out the details so we can leave out the property 
>> name if it is the same as the current method name, but for now I always 
>> explicitly include the name.
>> 
>> 
>> 
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> 
> 

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

Reply via email to