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 -~----------~----~----~----~------~----~------~--~---