Guys, responses below.
--rob
On 7/23/07, Stephan Beal <[EMAIL PROTECTED]> wrote:
On Jul 23, 4:06 am, Dave Methvin <[EMAIL PROTECTED]> wrote:
> All of those results make sense.
>
> > "print( (new String('foo') === new String('foo')))"
> > false
>
> Those are two different objects, even though they have the same value;
> object1 !== object2 by definition of the === operator.
Agreed.
What is this definition of the === operator you are referring to? I'm
unaware of it having ever been defined as a reference comparison, and having
read the relevant part of the ECMA Script specification yesterday I'm
certain it isn't.
Two primitives with the same type and value are === as well as ==
i probably would expect it for string constants, but i would not
expect it to be true for computed strings:
[EMAIL PROTECTED]:~$ SpiderApe -e "a=function(){return 'abc'[0];};
print(a() === 'a')"
true
That proves it isn't a by-reference comparison.
> > "print(typeof someUndefined == 'fuzzyDuck')"
> > false
>
> typeof someUndefined is 'undefined', and 'undefined' != 'fuzzyDuck'
This makes sense, of course, but seems to contradict the standard (as
Rob described it above).
No, it was my Sunday evening brain. I was thinking of 'someUndefined' as
being the LHS of the expression, but of course it isn't, it's 'typeof
someUndefined'. It will return true as long as y is the string 'undefined'.
According to the spec, === and == only differ in the algorithm's flow when
the type of the left and right expressions differ, so it is likely that my
(not uncommon) belief that === is faster than == is incorrect.
It is however the case that === is a safer comparison for a lot of
situations. Allowing type conversions to take place means that you may get
unexpected results, I have come across a situation where this happened
before and so use the strict (in)equality operators now to avoid problems in
future. If I want type conversion I make it explicit.
