2009/2/10 Jim Higson <j...@333.org>:
> 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
> oddly.
> 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
> String.
>> 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
> code.
> 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.
> --
> Jim
> blog: http://jimhigson.blogspot.com/
> web: http://wikizzle.org
> >

Ha. I'm relatively new to JS and I though that ...

var s_String = "bob";

was just a shortcut for

var s_LooksLikeAStringButDoesNotGoQuack = new String("bob");

I always thought that internally they were the same thing.

It seems truely strange that they are not. If that is indeed the case.

Yet I can call string methods on s_String just like I can on
s_LooksLikeAStringButDoesNotGoQuack though.

>>> s_String = 'bob';
>>> s_String.toUpperCase()
>>> o_String = new String('bob')
>>> o_String.toUpperCase()
>>> typeof o_String
>>> typeof s_String

There is a difference shown in FireBug in that o_String allows a
breakdown of ...

0       "b"
1       "o"
2       "b"

What does new String("bob") offer over normal "bob"?

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

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