2009/2/10 Jim Higson <j...@333.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.
>
> I think a lot of people who used Javascript for a long time think the
> same. Most languages they would be.
>
>> 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"?
>
> As far as I know, nothing. Hence my assertion that Prototype should
> treat object strings as if they were a normal string.
>
> The Moz docs say in a few places things like:
>
> "You should use string literals unless you specifically need to use a
> String object, because String objects can have counterintuitive
> behavior."
> https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Predefined_Core_Objects/String_Object
>
> But they don't give an example of this specific need. I dunno why
> someone would call new String(), but if they *do* create strings that
> way, IMO Javascript library code should treat them like native
> strings.
>
> --
> Jim
> blog:http://jimhigson.blogspot.com/
> web:http://wikizzle.org
> >
>
So, it seems the only place where things go wonky is with eval().
And the odd behaviour indicates that the toString() method isn't
called on a string object when using eval(). More wierd.
>>> s1 = "2 + 2"
"2 + 2"
>>> s2 = new String("3 + 3")
3 + 3
>>> eval(s1)
4
>>> eval(s2)
3 + 3
>>> eval(s2.toString())
6
This is just odd behaviour, but having read the MDC, it does explain
what happens internally when String methods are called in a text
string.
I wonder if the same sort of issues apply to
i_Seven = 7;
vs
o_Seven = new Number(7);
>>> i_Seven = 7
7
>>> o_Seven = new Number(7)
7
>>> typeof i_Seven
"number"
>>> typeof o_Seven
"object"
and boolean
>>> b_True = true
true
>>> o_True = new Boolean(true)
true
>>> typeof b_True
"boolean"
>>> typeof o_True
"object"
There are no additional properties on a Number or Boolean objects as
far as FireBug is reporting.
So, with boolean/string/number accessible as primitives AND objects,
then instanceof seems to be the way to identify things.
>>> o_String = new String("stringy string")
stringy string 0=s 1=t 2=r 3=i 4=n 5=g 6=y 7= 8=s 9=t 10=r 11=i 12=n 13=g
>>> s_String = "string string"
"string string"
>>> typeof o_String
"object"
>>> typeof s_String
"string"
>>> o_String instanceof String
true
>>> s_String instanceof String
false
Confusing.
--
-----
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
-~----------~----~----~----~------~----~------~--~---
