ES4 draft: Name

Lars Hansen lhansen at
Thu Mar 13 16:05:20 PDT 2008

> -----Original Message-----
> From: Waldemar Horwat [mailto:waldemar at] 
> Sent: 11. mars 2008 19:17
> To: Lars Hansen
> Cc: es4-discuss at
> Subject: Re: ES4 draft: Name
> > public function Name(a, b=undefined)
> > static meta function invoke(a, b=undefined): Name
> It would be help the spec's readability if the formal 
> parameters had more descriptive names than "a" and "b".  Here 
> it's not clear which one is which.
> > new Name( a, b=... )
> Ah, I see why the formal parameters were called "a" and "b".  
> I think that the design is too weird though -- one of the 
> parameters ought to be a name and the other one ought to be 
> an optional namespace.  If I have the following:
> var ns:Namespace = ...
> var id:string = ...
> and don't know anything about the ...'s, then I currently 
> can't just call:
>   n = new Name(ns, id);
> Instead, I must use:
>   if (ns !== null)
>     n = new Name(ns, id);
>   else
>     n = new Name(id, undefined);
> The reason is that, under the current specification, new 
> Name(null, x) requires x to be undefined (null is a Name).

Maybe that would be the better bug to fix -- allowing null
explicitly as a namespace to cover that case.

> [I'm assuming that the expression
>   null is T
> is true for any nullable type T.  If that's not the case, 
> then there are different issues here.]

That is the case.

> My preference would be to always have the identifier as the 
> first parameter and the namespace as the optional second 
> parameter.  This will avoid hassles with values like null 
> that can be either a namespace or a name.

As Igor pointed out that is incompatible with E4X, but that's
hardly a good reason.

(What we could be looking at here is an artifact of specifying
the language entirely with ES code, which is too weak to
express the idea of multiple interfaces to a function.)

I think it's desirable to keep the current order for compatibility
with existing designs (it's not like E4X sees no use).  I'll
try to clean up the constructor interface to be more robust /

> Is there a compelling reason to treat numbers between 0 and 
> 2^32-1 specially here?  It adds complexity and I'm not sure 
> what it's for.

It's because of EnumerableId, which treats values in that range
specially.  The thought behind the code the way it's written is
that if one wishes to construct a Name, then the parameters
must conform to those of EnumerableId: Name, string, or uint.
Otherwise there's a type error.

However, this is a little too hard-nosed, and EnumerableId
is changing anyway (if int and uint go away, as I expect they
will), so I'll probably remove the checking here, and just
add conversion to string for any argument at all.

> Creating the ambiguity of whether Name values appear to be 
> interned is likely to lead to trouble.  

Yes.  See separate thread that I spun off this one.

> > The |Name| constructor is implementation-dependent.
> What implementation-dependent behavior does it have, other 
> than the above?  Shouldn't it be normatively specified in
> the spec?

It's implementation-defined whether the result of this is true:

  x = new Name(a,b)
  y = new Name(a,b)
  x === y

but as discussed in that other thread, that problem needs to be
solved, so the problem with "implementation-defined" here should
go away.

> What is analyzeArgs?  It's defined but not used here.

"The helper function analyzeArgs, called by the Name constructor, takes
the two values a and b that were passed to the Name constructor and
returns an object containing a qualifier in the form of a namespace
(which may be null) and an identifier in the form of a string. The
qualifier and identifier are used to create the Name object."

> Why does valueOf do a toString on the Name?

Entirely because the original spec (on the wiki) required it.  I suspect
this is the wrong design (and I think even Brendan, who wrote it up,
questioned it, because it's left as an open issue on the wiki); the
ActionScript implementation of the E4X "QName" valueOf method returns
'this'; that is probably the right behavior here as well.


More information about the Es4-discuss mailing list