==, ===, and Name/Namspace (was: RE: ES4 draft: Name)
lhansen at adobe.com
Thu Mar 13 15:39:41 PDT 2008
(Partial followup to address one point and open a debate on it.)
> -----Original Message-----
> From: Waldemar Horwat [mailto:waldemar at google.com]
> Sent: 11. mars 2008 19:17
> To: Lars Hansen
> Cc: es4-discuss at mozilla.org
> Subject: Re: ES4 draft: Name
> Creating the ambiguity of whether Name values appear to be
> interned is likely to lead to trouble.
Agreed, this is not-good design. Ditto for Namespace, to the
extent it has the same problem.
> For example, if I create a Map<Name, ...> and insert the result of
> Name(ns, "abc")
> into it then it's unclear whether the value
> Name(ns, "abc")
> will be present in the map. It's at the implementation's
> whim. We should specify it one way or another; my preference
> is to make these indistinguishable, which can be done either
> by interning them when creating them or by making === not
> distinguish them.
I agree. All sealed "value types" in ES3 (primitive strings,
numbers, booleans) are indistinguishable to ===; Name and
Namespace are new value types in ES4 and should get the same
Firefox currently has that "new Namespace" (for E4X) produces
a new object that is == to another namespace produced with the
same string but not ===. From looking at the code, ActionScript3
does the same thing. Ditto for names (QName in E4X, not Name).
But in Firefox, Namespace is dynamic (not so in ActionScript) so
== but not === makes sense; if Namespace is not dynamic in ES4
we can get away with the changed behavior. Still, might pose
a backward compatibility risk. On the third hand, E4X is not
used on the web in general, only in apps targeted to FF and AS3.
"Name" is new in ES4 and we can do what we want.
Brendan, Igor, Jeff -- opinions about possible compatibility
issues with Namespace from E4X, given that we would want to
keep Namespace in ES4 immutable so that === makes sense?
(Presumably hash-consing is incompatible with current
More information about the Es4-discuss