<font size="2">Nothing is more important than looking cool :-).   But yes, that would definitely be another good reason to switch to that syntax.   And also to avoid the string manipulations needed in _WidgetBase.js to go from &quot;foo&quot; --&gt; _setFooAttr().</font><div>
<font size="2"><br></font></div><div><font size="2">I&#39;m just confused how DefineProperty() could do inheritance though; let us know if you find a solution for that.<br></font><br><div class="gmail_quote">2011/12/4 ben hockey <span dir="ltr">&lt;<a href="mailto:neonstalwart@gmail.com">neonstalwart@gmail.com</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">optimizing property names of objects is definitely one big part of what advanced mode does.  as stephen pointed out, renaming &quot;_setFooAttr&quot; to &quot;x&quot; breaks/changes all calls to widget.set(&#39;foo&#39;, xyz) since we expect the setter function to be named &quot;_setFooAttr&quot;.  however, if there are other things to be gained by advanced mode (which i understand there is) and we can stop (or work around or fix) the property name optimizations then we have a net gain.<div>
<br></div><div>hmm... i just had a thought about my recent compose.js ramblings.  i think you could make something similar to my DefineProperty work in a way that property name optimizations would still work.  in fact, rawld does something similar in backdraft and to be honest, i should give backdraft some credit as inspiration for playing with these ideas.</div>
<div><br></div><div>what i mentioned previously was this:</div><div><br></div><div><div>var MyWidget = WidgetBase.extend({</div><div><span style="white-space:pre-wrap">        </span>foo: DefineProperty({</div><div><span style="white-space:pre-wrap">                </span>get: function () {</div>
<div><span style="white-space:pre-wrap">                        </span>return this.foo;</div><div><span style="white-space:pre-wrap">                </span>},</div><div><span style="white-space:pre-wrap">                </span>set: function (value) {</div><div><span style="white-space:pre-wrap">                        </span>this.foo = value;</div>
<div><span style="white-space:pre-wrap">                </span>},</div><div><span style="white-space:pre-wrap">                </span>value: &#39;xyz&#39;</div><div><span style="white-space:pre-wrap">        </span>})</div><div>  });</div><div><br></div><div>
changing to the form below would probably be safe with property name optimizations since DefineProperty would actually return something like: </div><div>{</div><div><span style="white-space:pre-wrap">        </span>foo: ...</div>
<div><span style="white-space:pre-wrap">        </span>_setFooAttr: ...</div><div><span style="white-space:pre-wrap">        </span>_getFooAttr: ...</div><div>}</div><div><br></div><div>and the usage would be:</div><div><br></div><div>
<div>var MyWidget = WidgetBase.extend(DefineProperty(&#39;foo&#39;, {</div><div><span style="white-space:pre-wrap">        </span>get: function () {</div><div><span style="white-space:pre-wrap">                </span>return this[&#39;foo&#39;];</div>
<div><span style="white-space:pre-wrap">        </span>},</div><div><span style="white-space:pre-wrap">        </span>set: function (value) {</div><div><span style="white-space:pre-wrap">                </span>this[&#39;foo&#39;] = value;</div><div>
<span style="white-space:pre-wrap">        </span>},</div><div><span style="white-space:pre-wrap">        </span>value: &#39;xyz&#39;</div><div>}));</div></div><div><br></div><div>that&#39;s certainly a more substantial reason to use that style than just syntactic sugar or looking cool.  some property names probably still need to be quoted but &quot;helper&quot; functions like _setFooAttr don&#39;t need to be quoted everywhere since they&#39;re programatically generated and not actually mentioned in the source code.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">ben...</font></span><div><div class="h5"><br><div><br></div><div><br><div><div>On Dec 3, 2011, at 9:05 PM, Bill Keese wrote:</div>
<br><blockquote type="cite"><font size="2">Isn&#39;t the point of using closure [advanced mode] to optimize the export names (known in the old world as global variables)?   If it was just a question of optimizing local variables, shrinksafe etc. can do it.   I thought the charm of closure was that it converted every reference to &quot;getComputedStyle&quot; into &quot;g7&quot; or something.</font><div>
 <br></div><div><div class="gmail_quote">On Sun, Dec 4, 2011 at 10:55 AM, ben hockey <span dir="ltr">&lt;<a href="mailto:neonstalwart@gmail.com" target="_blank">neonstalwart@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 i was wondering about that issue myself...<br> <br> have you confirmed that this problem is NOT solved?  i haven&#39;t looked<br> at this in depth yet so i don&#39;t know if that was even considered.<br> however, i would imagine that it might be possible that if you could<br>
 make the closure compiler understand AMD then you might be able to<br> make it also realize that the property names for anything exported<br> from a module cannot be minified.  that&#39;s just a wild guess.  i think<br> if the compiler understood that much about AMD then it should work.<br>
 is that right?<br> <span><font color="#888888"><br> ben...<br> </font></span><div><div><br> On Dec 3, 2011, at 7:58 PM, Stephen Chung wrote:<br> <br> &gt; Sorry to disappoint you, but not so fast...  Translating AMD code to<br>
 &gt; Closure<br> &gt; modules is only the easy part.  The really hard part involves<br> &gt; automatic<br> &gt; handling of all property accesses via string names -- and all those<br> &gt; on(&quot;event&quot;...), _setXXXAttr() etc. calls, eliminate/translate-away<br>
 &gt; object<br> &gt; alias usages, as well as converting Dojo-style docs to Closure-style<br> &gt; JsDoc-variants.<br> &gt;<br> &gt; - Stephen<br> &gt;<br> &gt; -----Original Message-----<br> &gt; From: Chris Mitchell<br>
 &gt; Sent: Saturday, 3 December, 2011 6:25 AM<br> &gt; To: dojo dev.<br> &gt; Subject: Re: [dojo-contributors] Closure Compiler advanced<br> &gt; optimizations<br> &gt; with dojo/AMD code<br> &gt;<br> &gt; excellent!<br>
 &gt;<br> &gt; On Fri, Dec 2, 2011 at 5:14 PM, James Burke &lt;<a href="mailto:jburke@dojotoolkit.org" target="_blank">jburke@dojotoolkit.org</a>&gt;<br> &gt; wrote:<br> &gt;&gt; Malte Ubl has been doing some interesting transforms for AMD and<br>
 &gt;&gt; commonjs code to allow the use of advanced mode optimizations in<br> &gt;&gt; Closure Compiler on AMD code, and in particular on Dojo:<br> &gt;&gt;<br> &gt;&gt; <a href="https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f" target="_blank">https://plus.google.com/u/0/116910304844117268718/posts/5gLAFP4eK9f</a><br>
 &gt;&gt;<br> &gt;&gt; See his most recent comment.<br> &gt;&gt;<br> &gt;&gt; James<br> &gt;&gt; _______________________________________________<br> &gt;&gt; dojo-contributors mailing list<br> &gt;&gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
 &gt;&gt; <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br> &gt; _______________________________________________<br>
 &gt; dojo-contributors mailing list<br> &gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br> &gt; <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
 &gt;<br> &gt; _______________________________________________<br> &gt; dojo-contributors mailing list<br> &gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
 &gt; <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br> <br> _______________________________________________<br>
 dojo-contributors mailing list<br> <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br> <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
 </div></div></blockquote></div><br></div> _______________________________________________<br>dojo-contributors mailing list<br><a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
<a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br></blockquote></div><br></div></div></div></div></div></div><br>
_______________________________________________<br>
dojo-contributors mailing list<br>
<a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
<a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
<br></blockquote></div><br></div>