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';
"bob"
>>> s_String.toUpperCase()
"BOB"
>>> o_String = new String('bob')
bob
>>> o_String.toUpperCase()
"BOB"
>>> typeof o_String
"object"
>>> typeof s_String
"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
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
