<span style="color: rgb(0, 0, 0);">[</span><span class="EP8xU" style="color: rgb(0, 0, 0);">Maciej&#39;s latest message is a continuation of the following thread. </span>I have removed email addresses from the correspondence below to avoid helping spammers. This conversation took place on <span class="undefined"><font color="#000000">e-TC39 -at- <a href="http://ecma-international.org">ecma-international.org</a></font></span>]<br>
<br><div class="gmail_quote"><span style="font-size: large; font-weight: bold;">Forwarded conversation</span><br>Subject: <b class="gmail_sendername">ES3.1 Proposal Working Draft</b><br>------------------------<br><br><span class="undefined"><font color="#000000">From: <b class="undefined">Kris Zyp</b> <br>
Date: Feb 20, 2008 9:22 AM<br></font><br><br></span>I have been going through ES3.1 working draft and making some comments and<br>additions. However, one of the issues is rather broad. From what I<br>understand (and hope), ES3.1 is supposed to forward compatible with ES4, but<br>
it appears there are a large number of violations of this principle in the<br>ES3.1 Proposal Working Draft. These include:<br>- Secure Eval - (I commented on the page more specifics)<br>- Targeted additions - (I commented on the page more specifics)<br>
- typeOf - Doesn&#39;t exist in ES4<br>- richer reflection - Doesn&#39;t exist in ES4 (that I am aware of)<br>- arguments as Array - Simply needs to be corrected per Lars&#39;s comments.<br>- Deprecation section - These don&#39;t cite any ES4 deprecations, so I am not<br>
sure if these are really deprecated in ES4 (which is a requirement for<br>deprecation in ES3.1)<br><br>I also added Getters and Setters and Destructuring Assignment sections as we<br>believe these are very high priority additions for ES3.1.<br>
Thanks,<br><font color="#888888">Kris<br><br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Mark S. Miller</b> <br>Date: Feb 20, 2008 9:30 AM<br></font><br><br></span>I&#39;m confused. Doesn&#39;t this violate the &quot;no new syntax in ES3.1&quot; design rule?<br>
<font color="#888888"><br>--<br> &nbsp; &nbsp;Cheers,<br> &nbsp; &nbsp;--MarkM<br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Kris Zyp</b> <br>Date: Feb 20, 2008 9:36 AM<br></font><br><br></span>Indeed you are right. Is this really a core value of 3.1 to be preserved? It<br>
is quite possible for non-syntactical changes to have a larger impact than<br>syntactical changes. Syntax seems like a very arbitrary rule for deciding on<br>inclusion of additions.<br><font color="#888888">Kris<br></font><div>
<div></div></div>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Mark S. Miller</b> <br>Date: Feb 20, 2008 10:18 AM<br></font><br><br></span>It is arbitrary. I would be happy to replace it with another non- or<br>
less-arbitrary rule if we can quickly agree on one. But if we rely<br>only on our taste for minimalism, then how do we guard against the<br>following dynamic that I call &quot;The Tragedy of the Common Lisp&quot;:<br><br>
Each of us has some pet addition we think would be a great addition to<br>the language. &quot;const&quot;, &quot;decimal&quot;, getters and setters, destructing<br>assignment -- all these have come up just this morning!. Each of these<br>
makes the language larger and more complex, imposing a general diffuse<br>cost on everyone. When arguing about any one of these by itself in the<br>absence of a rule, each of us individually cares more to see our pet<br>feature adopted than to prevent someone else&#39;s particular pet feature<br>
from being adopted. This is one of the reasons design by committee<br>often goes bad.<br><br>Only by adopting some rule do we raise the stakes. We all know that to<br>agree to a feature that would violate the rule is to set a bad<br>
precedent and let open the floodgates of featuritis.<br><br>Language design should be more like writing a sonnet and less like<br>writing a phone book.<br><br>Again, shouldn&#39;t we be having this discussion on es4-discuss?<br>
<font color="#888888"><br>--<br> &nbsp; &nbsp;Cheers,<br> &nbsp; &nbsp;--MarkM<br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Kris Zyp</b> <br>Date: Feb 20, 2008 10:35 AM<br></font><br><br></span>I understand, although I think it is difficult to come up with a reasonable<br>
succint rule that can be applied effectively, when each feature addition is<br>really an ROI decision. We probably come up with a myriad of useless<br>features for any given rule. We may just need to be very stingy in our ROI<br>
evaluation.<br>On the otherhand, one rule that I think may be very valuable, is limiting to<br>prior implementation. Prior implementation precedence does provides a very<br>finite, limited set of possible features to choose from, and these features<br>
are of extra value since they improve cross-browser interoperability and<br>therefore have accelerated adoption opportunity. They also have benefitted<br>from real-world testing.<br>I am not insisting on a strict following of this rule, but I do think it<br>
could be a very useful rule and definitely keep the features to a small set.<br>There are also a number of features in the current working draft that could<br>be omitted on the basis of this rule (typeOf, reflection, tail recursion,<br>
etc).<br>I will let someone else make that call, definitely a much larger mailing<br>list :).<br><font color="#888888"><br>Kris<br><br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Maciej Stachowiak</b> <br>
Date: Feb 20, 2008 10:41 AM<br></font><br><br></span>&quot;No new syntax&quot; actually does create a meaningful benefit, which is<br>ability to do graceful degradation in browsers that don&#39;t support the<br>new language. New builtin types, properties and methods can be tested<br>
for from script before using it, but new syntax can&#39;t since the<br>presence of it alone will cause a syntax error at parse time. So it is<br>less arbitrary than some other possible rules.<br><br>Regards,<br><font color="#888888">Maciej<br>
<br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Mark S. Miller</b> <br>Date: Feb 20, 2008 10:54 AM<br></font><br><br></span>Ok, would anyone here mind if I forward the conversation so far to es4-discuss?<br>
<font color="#888888"><br><br>--<br> &nbsp; &nbsp;Cheers,<br> &nbsp; &nbsp;--MarkM<br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Kris Zyp</b> <br>Date: Feb 20, 2008 10:54 AM<br></font><br><br>
</span>True in the immediate future, but there will be a reverse effect down the<br>road. At some (hopefully) ES3.1 and higher will be pervasive enough that<br>devs just use it without detection, and only some browsers will support ES4.<br>
At this point having syntax already in ES3.1 means the syntax can be used,<br>and the methods/properties that we deferred to ES4 can be detected and used<br>optionally. At this point in the future, syntax that we don&#39;t include won&#39;t<br>
be useful for the reason you mention, but properties/methods we don&#39;t<br>include, can be detected and optionally used.<br><font color="#888888">Kris<br><br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Maciej Stachowiak</b> <br>
Date: Feb 20, 2008 11:53 AM<br></font><br><br></span><div><div></div></div>I am all for moving the discussion to es4-discuss.<br><font color="#888888"><br> &nbsp;- Maciej<br><br></font>----------<br><span class="undefined"><font color="#000000">From: <b class="undefined">Maciej Stachowiak</b> <br>
Date: Feb 20, 2008 11:54 AM<br></font><br><br></span><div><div></div></div>For information of those who might not be subscribed there yet, I&#39;ll<br>reply on es4-discuss.<br><font color="#888888"><br> &nbsp;- Maciej<br><br></font></div>
<br clear="all"><br>-- <br> &nbsp; &nbsp;Cheers,<br> &nbsp; &nbsp;--MarkM