On 8/16/06, David Green wrote:
$a=[1, 2, [EMAIL PROTECTED];
$c=[1, 2, [EMAIL PROTECTED];
$d=[1, 2, [EMAIL PROTECTED];
$a =:= $c; #false, different variables
$a === $c; #true, same elements make up $a and $c
$a eqv $c; #true, same elements therefore same values
$a === $d; #false, [EMAIL PROTECTED] and [EMAIL PROTECTED] are
different refs
So $a, $c, and $d may all have the same *value* (or "snapshot", when
evaluated all the way down through nesting and references), i.e.
they might be eqv, but only $a and $c are === because they have the
same contents [unevaluated contents] and $d doesn't.
OK, here's the counter-argument to my incessant ranting:
In the above example, $a and $c do "look" awfully similar, but
suppose we replace the anonymous arrays with named ones:
@X1=(1, 2, [EMAIL PROTECTED]);
@X2=(1, 2, [EMAIL PROTECTED]);
[EMAIL PROTECTED];
[EMAIL PROTECTED];
Now $a clearly does NOT === $b, because @X1 and @X2 are different
variables (that just coincidentally happen to share the same contents
at the moment). Replacing @X1 and @X2 with their anonymous
equivalents shouldn't suddenly change that.
[Well, anonymous object could have different rules, I suppose, but
it's no longer "obvious" that they should. Strings, for example, do
have special treatment to make different string-objects look the
same, but strings can't contain other variables, so it's easy to make
them act like plain values.]
However, it also follows that @X1 !=== @X2. There's no anonymous
reference hiding there, so why aren't @X1 and @X2 the same? (Well,
they just aren't!) So... probably what I wanted all along is just to
compare the contents of an array -- and === just isn't it. Hm.
=:= checks for same variable
=== checks for same object
eqv checks for same value
except that if the operands aren't objects, === will compare them as
values (like eqv). Or rather, if an item is a value (or an object
that ought to act like a value), just make sure its SKID (which ===
uses) compares in an appropriate value-like way.
-David
