super, self, and sideways & durable vs. template

Brendan Eich brendan at mozilla.com
Sun Jun 12 16:38:18 PDT 2011


On Jun 12, 2011, at 4:29 PM, Peter Michaux wrote:

>> Just to be clear to everyone following, you could use the closure pattern as Mark showed, for sure.
> 
> Yes. It seems that the major objection to the closure system is
> "efficiency". In the tradeoffs, some people weigh the extra memory
> and/or extra construction time heavily enough that the closure system
> does not appeal to them despite its other benefits.

Prototypal has fans otherwise, since it overtly shares via C.prototype.


> I'm trying to
> understand if the prototype side of the class proposal can do it all.

If there is only a class-body scope around prototype methods, then we avoid the per-instance unjoined function per method cost, yes.


>> If you wanted to expose log on the prototype, you'd need:
>> 
>> class Monster {
>> ...
>> function log(...rest) { /*...*/}
>> 
>> log = log;
>> 
>> attack(target) {
>>   log('The monster attacks ' + target);
>> }
>> }
> 
> If the log function is going to use the data of the object then does
> it require binding "this"?

It might not -- since it is class-private, the class can bind this when calling it explicitly via log.call or log.apply -- oops, you say that (must read ahead!):


>   log.call(this, 'The monster attacks ' + target);

But since log is class-private, we could pass |this| to it implicitly at no extra cost, when log is called from a method (prototype-homed function-valued property). Otherwise undefined would be passed as usual.

Would an implicit but not lexical (still dynamic, a 0th argument) |this| convention for private prototypal methods work? Formally I foresee some objecting. In practice it seems like it would work better this way than by wasting |this| on undefined and requiring explicit .call/apply.

/be


More information about the es-discuss mailing list