Subj : Re: Strange Rhino NativeString behavior
To   : netscape.public.mozilla.jseng
From : Andy Madigan
Date : Tue Oct 26 2004 08:49 pm

--- Brendan Eich <brendan@meer.net> wrote:

> Andy Madigan wrote:
> 
> > --- Matt McShane <mmcshane@email.com> wrote:
> > 
> >>In the meantime, if I were to try to hack a "no primitives" mode
> into
> >>
> >>Rhino (don't know how hard that would be - haven't even started
> >>looking) 
> >>would anyone be interested in hearing about it? If so, I can do
> some
> >>of 
> >>my thinking out loud here. If not, I'll do it and shut up.
> > 
> > 
> > I for one would be very interested in a "no primitives" mode, and I
> > have been wondering why JavaScript needed primitives in the first
> > place, the seem especially messy with Strings.
> 
> 
> Moreso for Rhino users than for SpiderMonkey users, because with Java
> 
> you have to interface with String objects more often.  With SM and
> the 
> DOM, you can deal with primitive strings for ages without storing a 
> property and wishing it persisted.

Yes, it may be true for Rhino more than SpiderMonkey, but I've dealt
with cases where a call to function might mean different thing based on
it's arguments. In this case, sometime you need to find out whether
something's a string, but you can't say "(bla instanceof String)" if
bla is a string primitive, nor can you say "(typeof bla == "string")"
if bla is a string object (typeof new String("bla") is "object"). I
actually can't think of a reason to attach a property directly to a
string, but trying to determine whether an object is a string or
something else is "messy". (e.g. some DOM methods, especially non-W3C
ones, have multiple optional parameters. Since JS doesn't have
overloading, there probably is a case somewhere where the DOM code has
to figure just what params were sent to it)

(Note: putting properties on strings seems like a bad idea to me from a
design point of view, unless you want certain strings to have extra
functions, that would be useful for tokenized data.)

Right now, to determine if a variable is a string, you must write
(assuming possible string x)

(x instanceof String || typeof x == "string")

It seems short, but it can make code harder to read, especially if you
don't know typeof. This is true for numbers, too.

> 
> > It seems one way to
> > implement this would be to change:
> > var a = "babble" from meaning a primitive string to meaning the
> > equivalent of 
> > var a = new String("babble")
> 
> 
> That's implicit in any unification.

I kind of figured I was stating the obvious here, but I was thinking
more along the lines that this would mean a change (honestly not sure
how big) where whatever method handles primitive string creation could
just invoke the String constructor once it had created the primitive,
so the way that primitves are read wouldn't have to be changed
completely, just enough to invoke the constructor. I'll probably take a
look at how primitives are handled in Rhino internally soon, since I've
kind of kept away from anything that might have to parse source
directly.

(That's probably also pretty obvious, but there probably are more
advanced routes, I imagine something like the change above could be
enclosed in a conditional in just one spot, instead of a possibly
bigger change)
> 
> /be

=====

.