I guess I'm being mr. grumpy today, but I had a small thought on this..<br><br>I think it's a mistake for dojo devs or users to think of anything going on in dojo as analgous to another programming language, unless the similarities are really close. (ie java/ c++ ) 
<br><br>The problem with this I think is that when you open that door you find users (like myself) that see words like &quot;inheritance/constructors/etc&quot; and start to expect other things to behave like java as well. Like superclass functions always being called on child classes. This can also lead to what I think are &quot;impure&quot; thoughts when you're a developer. If you allow yourself to slip back into thinking the way you did in another programming language you're not really seeing the &quot;matrix&quot; of the language you're actually coding in. If the dojo devs aren't see this supposed &quot;matrix&quot; then it seems like innovation and cool new features that intuitively leverage the JS language are less likely to come about as a result. 
<br><br><br><div><span class="gmail_quote">On 4/5/06, <b class="gmail_sendername">Bill Keese</b> &lt;<a href="mailto:bill@dojotoolkit.org">bill@dojotoolkit.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
&gt;&gt; 2. there is no separation between constructor initialization and instance<br>&gt;&gt; initialization.<br><br>The suggestion is something similar to this, right?<br><br>dojo.inherits(subclass, superclass, fnInit);
<br>dojo.extends(subclass, { param1: ..., func1: ... } );<br><br>(where fnInit is the constructor in the java sense of the word)<br><br>This is really abusing the meaning of &quot;inherit&quot;.&nbsp;&nbsp;Wouldn't it be better<br>
to combine these two functions into one function like this?<br><br>dojo.defineClass(subclass, superclass, fnInit,<br>&nbsp;&nbsp;{ param1: ..., func1: ... });<br><br>As a matter of fact, Alex has already done this for widgets (see<br>
<a href="http://archive.dojotoolkit.org/nightly/src/widget/Dialog.js">http://archive.dojotoolkit.org/nightly/src/widget/Dialog.js</a> )<br><br>PS: alternately you could use this syntax:<br><br>dojo.defineClass(subclass, superclass,
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{ constructor: ..., param1: ..., func1: ... });<br><br><br>&gt; I'd be interested in your thoughts on this:<br>&gt;<br>&gt; <a href="http://dean.edwards.name/weblog/2006/03/base/">http://dean.edwards.name/weblog/2006/03/base/
</a><br>&gt;<br>&gt; I wrote it to alleviate some of the problems you refer to below.<br>&gt;<br>&gt; -dean<br><br>Yeah, there was some discussion about this and some objections about not<br>staying true to javascript, but I didn't really understand it.&nbsp;&nbsp;(The
<br>current dojo stuff is just a thin wrapper on top of javascript and<br>people wanted to keep it that way, but not sure why.&nbsp;&nbsp;Maybe just<br>philosophical reasons.)&nbsp;&nbsp;Hopefully someone can explain in more detail.<br><br>Bill
<br><br>&gt; On 5 Apr 2006, at 23:51, Scott J. Miles wrote:<br>&gt;<br>&gt; At the Dojo meeting today (4/5/2006), dojo.inherits came up and we<br>&gt; agreed to<br>&gt; open up the discussion to the general contribs list.
<br>&gt;<br>&gt; There are two (arguable) faults in the dojo.inherits implementation:<br>&gt;<br>&gt; 1. invoking super class methods is wordy and inconvenient.<br>&gt; 2. there is no separation between constructor initialization and instance
<br>&gt; initialization.<br>&gt;<br>&gt; There is general agreement that we want to 'let JS be JS'.<br>&gt;<br>&gt; With regard to (2), my personal opinion is that JS doesn't have an axe to<br>&gt; grind with respect to initialization, and there is nothing un-JS about
<br>&gt; supporting a systemic instance initialization function (that is to say, a<br>&gt; standard way of specifying an instance initializer).<br>&gt;<br>&gt; Alex seemed right-away to have an idea of how tweak dojo.inherits
 to add<br>&gt; such a feature (yay). We briefly discussed adding additional parameters to<br>&gt; inherits vs. a key-word style signature. I prefer the former, but there was<br>&gt; no general agreement.<br>&gt;<br>&gt; There was some talk about the term 'inherits' implying a non-JS idiom, but
<br>&gt; this is not a problem IMO. Any suggestions for new nomenclature are<br>&gt; appreciated.<br>&gt;<br>&gt; Re (1), nobody seemed to have a handle on how to make calling<br>&gt; inherited/parent/base-class methods easier. Morris has developed his own
<br>&gt; inheritence system that may provide a solution.<br>&gt;<br>&gt; Thanks for listening. :)<br>&gt;<br>&gt; Regards,<br>&gt; Scott J. Miles<br>&gt; TurboAjax Group<br>&gt; <a href="http://www.turboajax.com">http://www.turboajax.com
</a><br>&gt;<br>&gt; _______________________________________________<br>&gt; dojo-contributors mailing list<br>&gt; <a href="mailto:dojo-contributors@dojotoolkit.org">dojo-contributors@dojotoolkit.org</a><br>&gt; <a href="http://dojotoolkit.org/mailman/listinfo/dojo-contributors">
http://dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>_______________________________________________<br>dojo-contributors mailing list<br><a href="mailto:dojo-contributors@dojotoolkit.org">dojo-contributors@dojotoolkit.org
</a><br><a href="http://dojotoolkit.org/mailman/listinfo/dojo-contributors">http://dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br></blockquote></div><br><br clear="all"><br>-- <br>Jesse Kuhnert<br>Tacos/Tapestry, team member/developer
<br><br>Open source based consulting work centered around dojo/tapestry/tacos/hivemind.&nbsp;&nbsp;<a href="http://opennotion.com">http://opennotion.com</a>