2008/8/25 Kris Zyp <[EMAIL PROTECTED]>: > > > 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? -- erik
_______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
