<br><br><div class="gmail_quote">On Sun, Apr 18, 2010 at 3:28 PM, Brendan Eich <span dir="ltr">&lt;<a href="mailto:brendan@mozilla.com">brendan@mozilla.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><div><div class="im"><div>On Apr 18, 2010, at 3:56 AM, Peter van der Zee wrote:</div><br><blockquote type="cite">On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich <span dir="ltr">&lt;<a href="mailto:brendan@mozilla.com" target="_blank">brendan@mozilla.com</a>&gt;</span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div>On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:<br> <br>
 <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> To be solved:<br> - Allow non-string-property keys<br> - Allow &quot;hidden&quot; properties, non-enumerable, not generically accessible (like stringed keys are now). To be honest, I&#39;m still not 100% clear on this one.<br>
 </blockquote> <br></div> I don&#39;t see how these two differ.</blockquote><div><br>Non-string property keys don&#39;t need to be hidden. The language could be extended in such a way where identity properties could be part of it. They could be enumerable. Some edge cases would have to be resolved of course.<br>
</div></div></blockquote><div><br></div></div>Existing code containing for-in loops over objects that could be passed in as arguments, or found in the heap, where the objects could now have object-keyed properties, would break if the keys were not converted to strings. But of course if converted to string, an object key would lose its identity and potentially collide, and in any event not name the same property it did. for-in loop bodies often use the enumerated key:</div>
<div><br></div><div>  for (var prop in obj) alert(o[i]);</div><div>  for (var prop in obj) assert(typeof prop == &quot;string&quot;);</div><div>  for (var prop in obj) if (obj.hasOwnProperty(prop)) alert(prop);</div><div>
<br></div><div>etc.</div><div><br></div><div>This gets back to versioning. If you assume we can make incompatible changes to the language, say under opt-in versioning, then there&#39;s still the problem of mixed versions of code interacting via the heap (shared function references allowing new objects to be passed to old functions, or just found in the heap by old functions via the global object or some other shared mutable object).</div>
<div><br></div><div>These are not &quot;edge cases&quot;. They suggest keeping any new object-keyed properties non-enumerable by definition, with no way to make such new properties enumerable. This then leads to the observations about garbage collection, equivalence with inverting obj[prop] to prop.get(obj) where prop is an <a href="http://wiki.ecmascript.org/doku.php?id=strawman:ephemeron_tables" target="_blank">EphemeronTable</a>, etc.</div>
<div><br></div><div><div class="im"><br></div></div></div></blockquote><div><br>Okay. So enumerating identity references would require changes that are not going to come. Check. It&#39;s not going to happen so any more discussion feels pointless.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div class="im"><blockquote type="cite"><div class="gmail_quote">
<div>The hidden properties could just as well be strings. You could have a public enumerable property and one that&#39;s private and hidden at the same time.<br></div></div></blockquote><div><br></div></div>If both are string-keyed, how would you access both from within the &quot;private&quot; boundary? There would still be one bit of difference between the keys. I&#39;m not soliciting a full proposal from you here, just suggesting this is not a clear enough proposal to evaluate.</div>
<div><br></div></div></blockquote><div><br>It would be the same as shadowing variables and your own responsibility. It&#39;s also a reason why I don&#39;t find it a feasible solution to extending the language. It&#39;s like a one time shot. Once you have it, all the backwards compat clash arguments would apply again. This feels like the wrong way because in the end we&#39;ll still need to use one of the other paths. I wouldn&#39;t prefer to introduce complexity into the language on this premise.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div></div><div><div class="im"><br><blockquote type="cite">
<div class="gmail_quote"><div>I can see these as distinct, That&#39;s why I&#39;m wondering whether everyone is trying to solve one with the other or actually pursuing either one (or both) of them. <br></div></div></blockquote>
<div><br></div></div>The names proposal has advantages beyond what a &quot;private string&quot; key idea could have, if there were a way to forge or equate the private string key. Names can&#39;t be forged.</div><div><br>
</div><div>If the private string key idea is indistinguishable with the Name object idea, then we are in agreement. The use of &quot;object&quot; in &quot;Name object&quot; is a straw concept currently. Perhaps there should be a new typeof result. I addressed this issue <a href="http://wiki.ecmascript.org/doku.php?id=strawman:ephemeron_tables" target="_blank">here</a>:</div>
<div><br></div><div>&quot;We have extant implementations and real code on the Web that assume <code>o[x]</code>
 will convert an object denoted by <code>x</code> to its string 
representation via <code>[[DefaultValue]]</code> (typically, <code>toString</code>)
 and use that string to identify the property of <code>o</code>. 
Changing the rules by making <code>Name</code> instances be of object 
type (<code>“object”</code> <code>typeof</code> result, <code>Object</code>
 type name in ECMA-262) breaks this contract. There is no string 
conversion of a <code>Name</code> instance that can be used to identify 
the property named by that instance in an object. <code>Name</code>s are
 different animals from strings and objects. Their type (typeof and 
abstract specification type) must make this clear.&quot;</div><div><br></div><div><div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>This could be fixed by some kind detection scheme for these directives.</div>
</div></blockquote><div><br></div></div>You can&#39;t detect new syntax except by embedding it in a string and eval&#39;ing the string inside a try/catch.</div><div><br></div></div></blockquote><div><br>You can add the directive and detect whether it has been activated at a later point, can&#39;t you? I mean, you can&#39;t in the current specification, but such a mechanism can be created... with backward compatibility in mind. This is of course all tied with the question of wanting to walk the versioning path to begin with. &quot;use strict&quot; seems to be recon in this regard... (as in, haven&#39;t we already started on this path?)<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div></div><div><div class="im"><br><blockquote type="cite">
<div class="gmail_quote"><div>But why was versioning going to be a problem at first and not any more?</div></div></blockquote><div><br></div></div>Because old browsers fade away. IE6 is taking its time but it will go away too. More modern browsers all auto-update, crucial for patching security bugs and promoting new versions to users who might otherwise get stuck at a buggy, unsafe old rev.</div>
<div class="im"><div><br></div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Harmony having new syntax does not mean we are opening up the design space to make some new, incompatible version of the language. You seem to allow for that as a possible future course, but TC39 members are uniformly against this path AFAICT. See <a href="http://wiki.ecmascript.org/doku.php?id=harmony:harmony" target="_blank">http://wiki.ecmascript.org/doku.php?id=harmony:harmony</a>.<br>
 <font color="#888888"> <br> /be<br> </font></blockquote></div><br>That was my proposal indeed. This also makes it impossible for introducing any and all kind of feature that would not be parsable by previous versions (like introducing new characters or the short function notation). It actually puts a great burden on the evolution of the language as a whole, doesn&#39;t it? Not sure whether that&#39;s a bad thing per se.<br>
</blockquote></div><br></div><div>The burden comes from the Web as it is, in my view. We don&#39;t get to start over. The decision whether or not to make a new and more freely incompatible variant of JS is, you&#39;re right, a choice. TC39 does not propose such a large change. It is likely to be bad for implementors and users. It would probably not converge in a usable new spec, based on design-by-committee. The odds of a market player evolving some new and more incompatible version is even lower.</div>
<div><br></div><div>The best course in TC39&#39;s view, I think I can safely say, is to extend the language in ways that address design flaws and gaps, and remove flawed constructs only after they fall into disuse. It is the extension via new syntax, more than extension of standard objects (but both can matter), that motivates this versioning discussion. And of course this gets back to the thread&#39;s topic: why did ES5 add &quot;static methods&quot; to Object.</div>
<div><br></div><div>I hope this helps clarify things.</div><div><br></div><font color="#888888"><div>/be</div></font></div></blockquote></div><br>I&#39;m a a little puzzled why Harmony would be okay to get new syntax, while at the same time refusing to go with new syntax in general. I mean, if you&#39;re going to change the language anyways... But I suppose that&#39;s just the way it is best acceptable to all parties, including the web.<br>
<br>Sorry for hijacking the thread, did not mean to. Thanks for the 
clarification.<br>
<br>- peter<br>