Re: Clawing my way out of operator overloading hell

[sauoq]

These scalars are not primitive strings, so clearly for this statement to be of any use, someone, somewhere in the inheritance hierarchy has overloaded the 'eq' operator.

Regardless of whether or not that is true in your case, it isn't a foregone conclusion in every case. If you know that two scalars contain references, a string comparison will tell you whether or not they refer to the same thing.

$ perl -le 'my $foo = \1; my $bar = $foo; print "same" if $foo eq $bar
+'
same

-sauoq
"My two cents aren't worth a dime.";

[halley]

While the string eq operator can check for reference equivalence, the numeric == operator is preferred for this sort of check. It seems that not many people note this message in perlref:
Using a string or number as a reference produces a symbolic reference, as explained above. Using a reference as a number produces an integer representing its storage location in memory. The only useful thing to be done with this is to compare two references numerically to see whether they refer to the same location.

By using the == instead of eq, you compare the addresses directly, rather than converting both operands to strings which happen to include identical character sequences.

They're functionally equivalent today, but I imagine someone may find some odd exploit involving stringified references. While I don't think Perl5 could possibly fix stringified references without breaking the semantic assumptions made in a metric buttload of scripts, it's good to get out of the habit of measuring proxied symptoms and instead use the proper operator.

--
[ e d @ h a l l e y . c c ]

[sauoq]

While the string eq operator can check for reference equivalence, the numeric == operator is preferred for this sort of check.

Sure. It is much more efficient. I only intended to let the OP know that the code he is maintaining might be doing something useful without operator overloading. (It turns out that I guessed right.)

By using the == instead of eq, you compare the addresses directly, rather than converting both operands to strings which happen to include identical character sequences.

Well, I wouldn't go as far as to say stringified references just "happen to include identical character sequences." They include identical character sequences because the same code produces those characters from the same input data.

They're functionally equivalent today, but I imagine someone may find some odd exploit involving stringified references.

An exploit? I would love to hear more about how you think someone might accomplish that. :-)

Yes, == is better than eq for checking reference equality. It's much faster. Use numerical comparison. Tell others to use numerical comparison. But, there is no reason to be paranoid about the construct. It isn't dangerous. It isn't deprecated. (afaik) It works fine; it's just slow.

P.S. I can even think of one good reason to use it. What if you have overridden '0+' and want to check for reference equality rather than the equality of two objects' overridden numification?

-sauoq
"My two cents aren't worth a dime.";