Yes, using == on references does not "reference arithmatic" make... (sierrathedog04 wrote
The Perl compiler ought to prohibit numeric operations on references.
). Perl doesn't support any numeric operations on references. It does support converting a reference to a number and then doing numeric operations on those. It certainly doesn't support converting a number (no matter how you got it) into a reference (nor does it support any operations that take a reference and a number as input and return a reference as output). So I don't understand the leap from == to fears of reference arithmatic.
I don't like using eq to compare references because it feels very much like comparing numbers via:
sprintf("0x%X",$num1) eq sprintf("0x%X",$num2)
(And if a design bug I found in overloading is ever fixed, I'm likely to overload the stringification of many of my objects but would never overload the numeric value of them so, if that were to happen, eq would become unreliable while == would continue to work. I think it makes sense to have objects return human-readable stringifications but don't see much use for numeric values of objects except as already provided for.)
Anyway, I wanted to point out that in (tye)Re: Creative use of pack/unpack I heavily abuse the numeric value of references in a way that I think only the insane would take seriously. In (tye)Re2: resurrecting objects? I hint that even more insanity is technically possible, though not even I have been insane enough to actually try that. ;)
-
tye
(but my friends call me "Tye")
| [reply]
[d/l] |
Numbers are by definition objects which we can add, subtract, increment, etc. I recall from thirty years ago that some guy named Peano generated the number system using these operations according to his Peano's Postulate.
That which cannot be added, incremented, etc. is not a number. A reference cannot be added, incremented, etc. Therefore a reference is not a number. The numeric comparison operator '==' is for comparing numbers. A reference is not a number. Therefore Larry and company should not permit the use of '==' to compare references, only numbers.
I also do not understand the statement that using '==' is more efficient when comparing references than is 'eq'. It seems to me that what we have here is an "amplifier that goes up to 11" type of argument (for those who have seen the film Spinal Tap.) Larry could simply take the algorithm that he uses for the '==' operator and use it for the 'eq' operator when comparing references (just as that amplifier maker could have taken whatever loudness he called 10 and instead called it 11.)
"Working on a sex farm. Poking your hay."—David St. Hubbins and Nigel Tufnel, "Sex Farm," Smell the Glove.
| [reply] |
"Numbers are not strings, therefore you shouldn't use eq
to compare references." You can't append references together.
You can't take substrings of references. etc.
I also do not understand the statement that using '==' is
more efficient when comparing references than is 'eq'.
[...] Larry could simply take the
algorithm that he uses for the '==' operator and use it
for the 'eq' operator when comparing references
Yes, you don't understand what is going on. The ==
operator has nothing special about it in regard to
references. The == operator just requests the numeric value
of its operands (or "evaluates them in a numeric context")
then compares the results. This is what it does for all
scalars whether they are references or not.
The eq
operator requests the string value of its operands and
then compares them. References return a descriptive string
that also includes their "pointer" value in hex. To make
the eq operator on references not require the construction
of this descriptive string would require that eq have
special code added to detect references and perform a
different operation. Such added code probably defeats the
point of trying to make eq on references more efficient.
-
tye
(but my friends call me "Tye")
| [reply] |