ES4 draft: Namespace
lhansen at adobe.com
Thu Mar 13 16:18:29 PDT 2008
> -----Original Message-----
> From: Waldemar Horwat [mailto:waldemar at google.com]
> Sent: 12. mars 2008 18:54
> To: Lars Hansen
> Cc: es4-discuss at mozilla.org
> Subject: Re: ES4 draft: Namespace
> Here's my review of this section:
> Is null a valid value of the class Namespace? The
> description states that it is a "final, non-dynamic, direct
> subclass of Object".
I don't recall us ever discussing whether it is nullable or
not. I have no strong opinions. There is a natural
initializer value for Namespace, namely the compatibility
namespace "noNS" (Jeff's writeup on these matters is
forthcoming). So it could be non-nullable.
Opinions from others are solicited...
> (Maybe this is addressed somewhere else, but I haven't seen
> it yet.) What do ==, <, etc. do on Namespaces? Can I create
> a Map with Namespace as the key?
As written up elsewhere, == and === probably ought to compare
two Namespace objects created from the same string [through the
use of the syntax
namespace ns = "mystring"
since there's no public constructor for Namespace] as equal.
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.)
Can you create a Map with a namespace as a key? Presumably
you mean with the default comparator and hashcode values. Yes,
you can, because the spec for intrinsic::hashcode says that
if v1 === v2 then we must have hashcode(v1) == hashcode(v2).
(Incidentally this means that the implementation for hashcode
must behave specially for Namespace and Name objects, once we
settle the rules for ===.)
More information about the Es4-discuss