==, ===, and Name/Namspace (was: RE: ES4 draft: Name)

# Lars Hansen (18 years ago)

(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 treatment.

However --

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 behavior too.)

(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
treatment.

However --

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
behavior too.)

--lars

# Brendan Eich (18 years ago)

On Mar 13, 2008, at 3:39 PM, Lars Hansen wrote:

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

All per ECMA-357, the E4X spec.

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.

This is a non-issue, AFAIK. See my earlier post on E4X.

No interoperable web content uses E4X, and the Firefox-hosted E4X
implementation could be versioned to support the old way, in the
worst-case -- if there were significant Firefox-only content whose
owners were unwilling or unable to upgrade their code.

I doubt that any such code exists, but the approach I would favor,
given an incompatible but better ES4 spec, would be to try to break
support for such code early during a major Mozilla milestone cycle,
to smoke out any customers and then persuade them to revise their to
satisfy ES4's rules.

I know of no E4X code that depends on current identity and mutability
rules. Zwetan (for AS3), Jeff Walden, and others may have thoughts,
so thanks for posting this to the list.

On Mar 13, 2008, at 3:39 PM, Lars Hansen wrote:

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

All per ECMA-357, the E4X spec.

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

This is a non-issue, AFAIK. See my earlier post on E4X.

No interoperable web content uses E4X, and the Firefox-hosted E4X  
implementation could be versioned to support the old way, in the  
worst-case -- if there were significant Firefox-only content whose  
owners were unwilling or unable to upgrade their code.

I doubt that any such code exists, but the approach I would favor,  
given an incompatible but better ES4 spec, would be to try to break  
support for such code early during a major Mozilla milestone cycle,  
to smoke out any customers and then persuade them to revise their to  
satisfy ES4's rules.

I know of no E4X code that depends on current identity and mutability  
rules. Zwetan (for AS3), Jeff Walden, and others may have thoughts,  
so thanks for posting this to the list.

/be