extracting namespace from a property

Peter Hall peter.hall at memorphic.com
Thu Feb 15 02:38:44 PST 2007


It seems very counter-productive to introduce a new Name type. Surely
it can only reduce E4X integration with ES4?

Peter


On 2/6/07, Brendan Eich <brendan at mozilla.org> wrote:
> On Feb 5, 2007, at 7:05 PM, Yuh-Ruey Chen wrote:
>
> > Brendan Eich wrote:
> >>    intrinsic static function invoke(ns : Namespace, id : string) :
> >> Name
> >>      new Name(ns, id);
> >>
> >
> > invoke is called when Name is called as a function, right?
>
> Yes.
>
> >> An enumerating for-in loop or comprehension must reflect an
> >> enumerable property name as a Name instance if the property was
> >> defined with an explicit or default namespace other than public.
> >> Otherwise, with no or a public namespace, enumerating for-in reflects
> >> the name as a string per ES1-3 and existing JS implementations.
> >>
> >
> > Although this helps, it would still be a hassle to have to check
> > whether
> > an enumerated property n is a Name or String. I can't do
> > n.identifier if
> > n is a String.
>
> You have to use 'switch type' or equivalent.
>
> > How about this: Each enumerated property n is always an instance of
> > Name. If n doesn't have a qualifier, n.qualifier would be null, while
> > n.identifier would be n's id. Thus, to get a property's id,
> > n.identifier
> > would work regardless of whether n has a qualifier. typeof(Name) would
> > be "string". Name's prototype would be a String, so name instanceof
> > String is true. These two requirements should be enough to satisfy ES3
> > compatibility.
>
> That's far from clear, because ES3 mandates a primitive string, not a
> String object. This will break any for-in loop that compares the
> iterating variable to a saved value of that same variable (since ==
> on Strings and other objects is identity, not string value comparison).
>
> You make a good point about this identity being important:
>
>    'foo' in obj === Name(null, 'foo') in obj
>
> The cost of a Name being cons'ed for every iteration of for-in is
> also troubling, in optimization effort if not in runtime and space if
> one argues that it could be optimized away. SpiderMonkey stores 31-
> bit int ids in tagged machine words, not as strings -- never mind as
> anything like Name instances.
>
> /be
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>



More information about the Es4-discuss mailing list