names [Was: Approach of new Object methods in ES5]

Peter van der Zee ecma at qfox.nl
Sun Apr 18 07:00:11 PDT 2010


On Sun, Apr 18, 2010 at 3:28 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Apr 18, 2010, at 3:56 AM, Peter van der Zee wrote:
>
> On Sun, Apr 18, 2010 at 7:19 AM, Brendan Eich <brendan at mozilla.com> 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<http://wiki.ecmascript.org/doku.php?id=strawman:ephemeron_tables>,
> etc.
>
>
>
Okay. So enumerating identity references would require changes that are not
going to come. Check. It's not going to happen so any more discussion feels
pointless.

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.
>
>
It would be the same as shadowing variables and your own responsibility.
It's also a reason why I don't find it a feasible solution to extending the
language. It'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'll still need to use one of the other paths. I
wouldn't prefer to introduce complexity into the language on this premise.


> 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<http://wiki.ecmascript.org/doku.php?id=strawman:ephemeron_tables>
> :
>
> "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, Objecttype 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.
>
>
You can add the directive and detect whether it has been activated at a
later point, can't you? I mean, you can'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. "use strict" seems to be recon in this regard... (as in,
haven't we already started on this path?)


>
> 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
>

I'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're
going to change the language anyways... But I suppose that's just the way it
is best acceptable to all parties, including the web.

Sorry for hijacking the thread, did not mean to. Thanks for the
clarification.

- peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100418/62d0f0c6/attachment.html>


More information about the es-discuss mailing list