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
