super, self, and sideways & durable vs. template

Brendan Eich brendan at
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( { /*...*/}
>> 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 or log.apply -- oops, you say that (must read ahead!):

>, '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.


More information about the es-discuss mailing list