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