2008/8/25 Kris Zyp &lt;<a href="mailto:kris@sitepen.com">kris@sitepen.com</a>&gt;:<br>&gt; &nbsp;<br>&gt;<br>&gt; 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&#39;s MI, both!). Copying is fine for a zero-inheritance classes-as-sugar proposal. The prototype stuff, as Kris points out, is different.<br>
&gt; &nbsp;<br>&gt;<br>&gt; To be clear, we use prototype inheritance&nbsp;as the rule, copying is the exception, only done as needed to acheive MI. I don&#39;t think I would characterize prototypical inheritance as Dojo&#39;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.<br>
<br><br>I&#39;ve been quiet on these threads for a long time but i just wanted to emphasize Kris&#39;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.<br>
<br>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?<br>
<br>-- <br>erik