ES4 draft: Namespace

Lars Hansen lhansen at
Thu Mar 13 16:43:09 PDT 2008

> -----Original Message-----
> From: Waldemar Horwat [mailto:waldemar at] 
> Sent: 13. mars 2008 17:35
> To: Lars Hansen
> Cc: es4-discuss at
> Subject: Re: ES4 draft: Namespace
> Lars Hansen wrote:
> > The natural behavior on < etc would be as in ES3, ie, if valueOf on 
> > namespace returns "this", as is most natural, then the
> > toString() operator ends up being called, and the string 
> names of the 
> > namespaces would be compared.  Since the string 
> representation is not 
> > specified, there is no specified ordering, but unless the 
> > implementation randomizes the output of toString, it should 
> at least 
> > be dependable per-implementation.  We could add a constraint to 
> > toString that says that if two namespaces
> > N1 and N2 are created from strings S1 and S2 then N1 and N2 compare 
> > the same as S1 and S2.  (For unforgeable namespaces -- 
> those created 
> > without an explicit string name -- all bets are off, and no two are 
> > equal.)
> Do we ever want to allow for any ordered containers analogous 
> to C++'s map<> and set<>?  If we were to define one then this 
> could cause problems because an ordered container typically 
> uses a less-than comparison function and considers x and y to 
> be equal if neither x < y nor y < x holds.
> The actual order wouldn't matter, as long as two different 
> namespaces wouldn't appear equal to each other in the above sense.

I suppose we could simply state that two Namespaces yield the same
string value iff they are ===, and that two invocations of toString()
always yields the same string.  Doesn't seem particularly onerous,
it would probably be the case in most implementations anyhow.

Then the same property for Name follows, since the string representation
for a Name is defined to be either the identifier string if there's no
Namespace part or the concatentation of the string representation of
its Namespace, "::", and its identifier string otherwise.


More information about the Es4-discuss mailing list