>> I don’t know if this has been discussed, but I find the |super| work-around >> provided by YUI and CoffeeScript (in the generated code) not that bad: >> >> ThisClass.__super__.foo.call(this, arg1, arg2); > > I'm not sure what you mean. If we add 'super', surely we want more than the > __super__ hack. We also want a callable expression 'super' in constructors, > and a 'super.foo' form for method and other property accesses from subclass > methods. We don't want people writing out .call by hand.
Agreed. As a hack, it already accomplishes a lot of what |super| is supposed to, mainly not hardcoding the name of the super-class. >> With ThisClass.__super__ pointing to SuperClass.prototype. > > The CoffeeScript compiler can lexically bind ThisClass and wire up __super__ > with generated runtime helper code. That's all backstage of the CoffeeScript > *language*, though. > > >> As a completely static solution, one could maybe expand a super-call >> super.bar(x, y); >> to >> __CurrentObject__.[[Prototype]].bar.call(this, x, y); >> >> On the other hand, I don’t know if a reference to __CurrentObject__ is ever >> available for some kind of static expansion. > > Are you talking about |here| again, with a new name? Sorry for the confusion. ;-) I think there is a subtle difference between the two (at least as I use them): - |here|: dynamic, computed as part of the property lookup, closely related to |this|. - __CurrentObject__ (or possibly a better name): Static, only available inside an object literal. > There is no static counterpart other than the one Allen proposed, the object > literal directly containing the method that uses 'super'. That would be enough. I guess I’m suggesting then to implement “super” like CoffeeScript does. Wouldn’t that be simpler? -- Dr. Axel Rauschmayer a...@rauschma.de twitter.com/rauschma home: rauschma.de blog: 2ality.com _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
