Re: RFC eq and ==
[EMAIL PROTECTED] (Chromatic) writes: Is 10 a string? Is it a number? Is 10base-T a string? Is it a number? Is an object with overloaded stringification and numification a number? Is it a string? I don't know a good heuristic for solving these problems. If you have one, it's worth considering though. Use =~ for all these kinds of comparison. No, I'm not being facetious, at least not intentionally. -- At Friday's meeting I did get a chance to call a spade an earth-moving bloody implement of damn-and-blasted wood and bastard metal construction. - Red Drag Diva
Re: RFC eq and ==
On Mon, 2004-05-17 at 17:13, chromatic wrote:
As Luke suggests, there's also programmer clarity to consider. If
determining how to compare depends on how you've used the variables to
compare, is it harder to understand the code?
To be specific, what does:
my $a = foo();
my $b = bar();
if $a == $b {
baz();
}
mean? Is it a numeric comparison? String? What?
The reason we need == and eq is to allow the programmer to specify which
behavior they wish. It really is that simple.
Now, that brings us to an ugly little bridge for higher level objects,
of course. What does it mean to override infix:== or infix:eq and which
would you override when?
It's going to have to be a matter of convention, but I would suggest
that things which feel numeric should provide an == and things that
feel stringy should provide an eq, but not both unless they are
actually different in some relatively obvious way to the casual Perl
programmer.
That means that while a matrix class might define ==, it probably should
not defined eq (though it might be serializable in some way that makes
eq possible through conversion). Similarly, a class that represents a
DNS zone should probably provide an eq, but not ==.
All that make sense?
--
Aaron Sherman [EMAIL PROTECTED]
Senior Systems Engineer and Toolsmith
It's the sound of a satellite saying, 'get me down!' -Shriekback
RFC eq and ==
Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? Or the will is to keep eq, gt and the others. (not very nice emho). Regards. -- Pedro Larroy Tovar | Linux Network consultant | piotr%member.fsf.org Software patents are a threat to innovation in Europe please check: http://www.eurolinux.org/
Re: RFC eq and ==
On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote: Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? How does the compiler know which is which? Is 10 a string? Is it a number? Is 10base-T a string? Is it a number? Is an object with overloaded stringification and numification a number? Is it a string? I don't know a good heuristic for solving these problems. If you have one, it's worth considering though. -- c
Re: RFC eq and ==
On Mon, May 17, 2004 at 01:42:26PM -0700, chromatic wrote: On Mon, 2004-05-17 at 13:35, Pedro Larroy wrote: Would it be a good idea to make ==, and other numeric comparators polymorphic so they can be used also for string comparisons? How does the compiler know which is which? Is 10 a string? Is it a number? Is 10base-T a string? Is it a number? Is an object with overloaded stringification and numification a number? Is it a string? I don't know a good heuristic for solving these problems. If you have one, it's worth considering though. -- c I thought perl internally would know. At least in perl5 it has to know somehow, since you can $var++ when is numeric and also when it's a string, and behaves different in each case. Regards. -- Pedro Larroy Tovar | Linux Network consultant | piotr%member.fsf.org Software patents are a threat to innovation in Europe please check: http://www.eurolinux.org/
Re: RFC eq and ==
Pedro Larroy writes:
Would it be a good idea to make ==, and other numeric comparators
polymorphic so they can be used also for string comparisons? Or the
will is to keep eq, gt and the others. (not very nice emho).
It was decided long ago that the distinction between == and eq is going
to stay. En mi humilde opinin, the idea is not archaic, but quite
modern. Or postmodern Larry would say, though I don't really understand
what that means.
Since scalars are polymorphic, their operations must not be. The
problem is the same as that of using + for string concatenation (which
has been proposed far too many times). A big part of Perl is the
ability to do:
my $a = 43;
$a += 1;
$a ~= bananas; # 44 bananas
And the ability to keep the semantics the exact same if you happen to
put quotes around the 43... or read it in from a file, for instance.
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
But it's been pointed out:
if +(some($big+%nastyexpression)) == +$b {...}
Now it takes three, maybe four re-scans to figure out that it's a
numeric comparison. Kills readability.
Fortunately for the generic programmer there's a generic equality which
returns true when objects are the same type (or almost the same, like an
integer and a string that looks like an integer), and false otherwise.
Larry called it equal, though equals seems much, much better.
if $a equals $b {...}
There's your polymorphic equality, if you will. I'd be wary of using
it often, however.
Luke
Re: RFC eq and ==
On Mon, 2004-05-17 at 13:51, Pedro Larroy wrote: I thought perl internally would know. At least in perl5 it has to know somehow, since you can $var++ when is numeric and also when it's a string, and behaves different in each case. True. Perl 5 scalars do keep track of the context in which you've used the data they hold. If you treat a scalar like a number, it'll behave like a number. There are some wacky corner cases, though, where you see side-effecty action at a distance. (I remember running across this at least twice, though I don't remember specific examples. DWIM usually works well.) As Luke suggests, there's also programmer clarity to consider. If determining how to compare depends on how you've used the variables to compare, is it harder to understand the code? The solution for an API designer may be be very careful, then! but I'm not sure a language designer has that luxury. -- c
Re: RFC eq and ==
Luke Palmer wrote:
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
Hmm.
In my head, I would expect == to have implicit numification on the
operands (unless user-overloaded to something else, but that's
different). In turn, I'd expect eq to have implicit stringifies.
Therefore I'd expect the +'s to redundant in the first example.
I'd then expect the second example to first convert $a and $b to strings
because of the ~'s, then, because it sees the ==, it would numify those
strings and do a numeric compare.
Are my expectations misaligned here?
-- Rod
Re: RFC eq and ==
Rod Adams writes:
Luke Palmer wrote:
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
Hmm.
In my head, I would expect == to have implicit numification on the
operands (unless user-overloaded to something else, but that's
different). In turn, I'd expect eq to have implicit stringifies.
Therefore I'd expect the +'s to redundant in the first example.
I'd then expect the second example to first convert $a and $b to strings
because of the ~'s, then, because it sees the ==, it would numify those
strings and do a numeric compare.
Are my expectations misaligned here?
Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a
polymorphic operator.
You're correct in terms of the current (and hopefully continuing) state
of things.
Luke
Re: RFC eq and ==
Luke Palmer wrote: Oh, sorry, wasn't clear. That's *if* eq was eliminated and == became a polymorphic operator. You're correct in terms of the current (and hopefully continuing) state of things. Went back and re-read your first post, and that is indeed what you were saying, I just read it too fast. I'd be seriously annoyed if eq went away. It's one of those things that makes Perl Perl. It's up there with the postfix if. ~$a == ~$b feels too much like: Cast(String, $a).Compare(Cast(String, $b)) -- Rod
Re: RFC eq and ==
Luke Palmer skribis 2004-05-17 14:54 (-0600):
Admittedly, if you use == for everything, you can force string or
numeric comparison this way:
if +$a == +$b {...} # numeric
if ~$a == ~$b {...} # string
And $a :=: $b could be written as \$a == \$b. Oh, hm.
It does sound kind of attractive to me, because it's a bit like
lc $a eq lc $b
Juerd
