On Feb 8, 1:19 pm, RobG <rg...@iinet.net.au> wrote:
> On Feb 8, 12:55 am, Jim Higson <j...@333.org> wrote:
> > alert( Object.isString( "foo" ));
> > // alerts "string"
> It alerts true.

So it does ^-)

> > alert( Object.isString( new String( "foo" ) ));
> > // alerts "object"
> It alerts false.

^-) again

> > I know why this happens - because Prototype uses the underlying typeof's
> > understanding of type.
> That typeof returns the type is pretty reasonable given that it is
> called "typeof".

> > Personally I think this is a bug though - Javascript is just being difficult
> > here
> It's a bit unfair to blame the language for what you consider an
> inappropriate use of one of its features.  Perhaps the name of the
> function should be "isStringPrimitive".

I guess I *am* blaming Javascript for having (in effect) two string
types. No other languages do this and (as far as I know) having two
kinds of strings doesn't let you do any cool stuff that you couldn't
do with one.

I see having two string types as one of those strange quirks of
Javascript that libraries like Prototype should smooth over so the
programmer can just think "...Ok I've got a string..." without
worrying which of the types of strings s/he has.

> > and Prototype should make stuff like this easier. It should
> > return "string" regardless of how the string was created.
> It is extremely rare to come across a String object in javascript, so
> there seems very little point in an isString function when the vast
> majority of the time a typeof test is sufficient (and less
> problematic).

Personally, I think the rareness of String objects is part of the
reason why it *is* desirable to take them into the account. As a
programmer you make assumptions that you're dealing with normal
strings, then suddenly an object String turns up everything breaks.
But you come to debug and the object string looks a lot like a normal
string and the bug takes ages to track down.

I started this thread when some library code I use started acting
It turns out this was because some other code (which I didn't write)
was passing new String('foo') into it.

Off the top of my head, my code was something like:

if( Object.isString( foo ) ){
   do something( foo );
}else if( Object.isObject( foo ) ){
   foo.each( function( i ){ /* ... */ } )

So given a String object was iterating through each char in the

> In the unlikely event that you want to know if the thing you have is a
> String object, use instanceof.  What is the use of an isString
> function that can't tell the difference between an object and a
> primitive?

I think treating them as both just Strings makes for easier to read

At the moment I test like this:

if( Object.isString( foo ) ||
  ( Object.isObject( foo ) && foo.constructor == String ) ) {

I can't think of any reason why I'd want to react to primitive Strings
differently from string objects, so I think just writing this makes
clearer code:

if( Object.isString( foo ) ) {

> I can't conceive of a scenario where a String object would be used and
> I'd get into a situation where I needed to test for something that was
> either an object or a string.  If it doesn't matter, why use an
> object?

Because I can't always control the values that are passed to functions
that I write. I don't know of any good reason why one would create a
String object, but if some client code does I should at least handle
it gracefully.

> And if it did matter, I'd want to test for one or the other
> in which case neither the current isString or your suggested
> modification would do the job.

Can you give examples of where it would matter?

> Perhaps is should return one of three values: primitive, object or
> boolean false.  Then if you don't care, you can use use:
>   if (isString(...)) ...
> as either 'object' or 'primitive' will resolve to true, but boolean
> false will be false.
> If you do care, you can use:
>   if (isString(...) ==  'primitive') ...

I think this is a very neat solution :-)

> The bottom line is to look at why you would use such a function, and
> whether there are already suitable language features that do the job.
> > Anyone agree I should file this as a bug, or is there a good reason the
> > current behaviour is desirable?
> It can hardly be called a bug when it does what the documentation says
> it does (I think "works as designed" is the polite response).  The
> function itself is a bit pointless though, as are similar functions
> like isNumber, e.g.

Ok, but it can "work as designed" and the design can be sub-optimal.

blog: http://jimhigson.blogspot.com/
web: http://wikizzle.org
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to