The two-arguments Name constructor follow E4X where the corresponding constructor for QName has the form:
QName(namespace, id) Regards, Igor On 12/03/2008, Waldemar Horwat <[EMAIL PROTECTED]> wrote: > > 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). > > [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.] > > > 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. > > > 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. > > > Creating the ambiguity of whether Name values appear to be interned is > likely to lead to trouble. 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. > > > > 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? > > What is analyzeArgs? It's defined but not used here. > > > Why does valueOf do a toString on the Name? > > > Waldemar > _______________________________________________ > Es4-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss > _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
