Look Ma, no "this" (was: ECMAScript Harmony)
erik.arvidsson at gmail.com
Mon Aug 25 19:07:53 PDT 2008
2008/8/25 Kris Zyp <kris at sitepen.com>:
> A lot of Ajax widgets, e.g. Dojo, use their own inheritance models, often
based on copying properties (sometimes based on prototypes; in the case of
Dojo's MI, both!). Copying is fine for a zero-inheritance classes-as-sugar
proposal. The prototype stuff, as Kris points out, is different.
> To be clear, we use prototype inheritance as the rule, copying is the
exception, only done as needed to acheive MI. I don't think I would
characterize prototypical inheritance as Dojo's own, where the inheritance
model becomes more library specific is in how constructor calls, super
calls, and inheritance trails are handled. However, almost every library I
am aware of uses prototype-based inheritance for pseudo-classes, and
consequently there is a level of compatibility. Dojo could create a class
that extends a Prototype (the library) class, and vice versa (at least
theoritically this should be viable without too much problem). This why I
would like to ensure that class sugar also used a prototype-based model, so
existing class structures are compatible with the new syntax.
I've been quiet on these threads for a long time but i just wanted to
emphasize Kris's point. Whatever we decide to desugar the class syntax into
I think it is very important to get this right. We need to make classes work
with existing prototype based inheritance chains. I would consider it a
failure if I cannot create a class that inherits from dijit.TabPane or from
a Prototype UI component for that matter.
I would also like to know more about the arguments why people seem to be set
on a zero inheritance class model? Does that imply that one can still
achieve inheritance using prototypes or does it mean that inheritance is not
desired at all?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss