On Apr 18, 2010, at 3:56 AM, Peter van der Zee wrote:
On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich <[email protected]>
wrote:
On Apr 17, 2010, at 6:07 PM, Peter van der Zee wrote:
To be solved:
- Allow non-string-property keys
- Allow "hidden" properties, non-enumerable, not generically
accessible (like stringed keys are now). To be honest, I'm still not
100% clear on this one.
I don't see how these two differ.
Non-string property keys don'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.
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:
for (var prop in obj) alert(o[i]);
for (var prop in obj) assert(typeof prop == "string");
for (var prop in obj) if (obj.hasOwnProperty(prop)) alert(prop);
etc.
This gets back to versioning. If you assume we can make incompatible
changes to the language, say under opt-in versioning, then there'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).
These are not "edge cases". 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 EphemeronTable, etc.
The hidden properties could just as well be strings. You could have
a public enumerable property and one that's private and hidden at
the same time.
If both are string-keyed, how would you access both from within the
"private" boundary? There would still be one bit of difference between
the keys. I'm not soliciting a full proposal from you here, just
suggesting this is not a clear enough proposal to evaluate.
I can see these as distinct, That's why I'm wondering whether
everyone is trying to solve one with the other or actually pursuing
either one (or both) of them.
The names proposal has advantages beyond what a "private string" key
idea could have, if there were a way to forge or equate the private
string key. Names can't be forged.
If the private string key idea is indistinguishable with the Name
object idea, then we are in agreement. The use of "object" in "Name
object" is a straw concept currently. Perhaps there should be a new
typeof result. I addressed this issue here:
"We have extant implementations and real code on the Web that assume
o[x] will convert an object denoted by x to its string representation
via [[DefaultValue]] (typically, toString) and use that string to
identify the property of o. Changing the rules by making Name
instances be of object type (“object” typeof result, Object type name
in ECMA-262) breaks this contract. There is no string conversion of a
Name instance that can be used to identify the property named by that
instance in an object. Names are different animals from strings and
objects. Their type (typeof and abstract specification type) must make
this clear."
This could be fixed by some kind detection scheme for these
directives.
You can't detect new syntax except by embedding it in a string and
eval'ing the string inside a try/catch.
But why was versioning going to be a problem at first and not any
more?
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.
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 http://wiki.ecmascript.org/doku.php?id=harmony:harmony
.
/be
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't it? Not sure whether that's a
bad thing per se.
The burden comes from the Web as it is, in my view. We don't get to
start over. The decision whether or not to make a new and more freely
incompatible variant of JS is, you'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.
The best course in TC39'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's topic: why did ES5 add "static
methods" to Object.
I hope this helps clarify things.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
