> Luke Palmer:
> # The first thing I noticed was the == / eq distinction. This
> # has been invaluable for scripting, but since Perl 6 is
> # desiring to be more of a formal language, I'm wondering
> # whether the distinction is profitable. In generic programming
> # (my specialty :), it is very useful to have a standard sort
> # of equality[*] that all participating objects define.
>
> Your desired "standard sort of equality" is provided by smartmatch.
>
> $a ~~ $b
Don't get too hasty here, I actually did put some thought into this.
Smart match was not what I was thinking of. I don't think two hashes
should be considered equal if their key intersection is nonempty.
> # The solution that springs to mind is to conform to other
> # languages' thought and make == polymorphically compare
> # equality. Thanks to context-forcing, the string/numeric
> # distinction is still there, at the expense of a little extra
> # verbosity:
> #
> # +$a == +$b; # Numeric compare
> # ~$a == ~$b; # String compare
> # $a == $b; # Generic compare
>
> Conciseness and precision are lost. What's gained?
I<One> solitary equality operator. Remember, I'm considering this
from a generic programmer's point of view. I'm already aware that the
== eq distinction is useful for scripting.
class Map {
method insert(Pair $p) {
push @.elems: $p;
}
method get($key) {
for (@.elems) { return $_.value if $_.key == $key }
}
has Pair @.elems;
}
Or should that have been C<$_.key eq $key>? It certainly shouldn't have
been ~~ (lest this work:)
my Map $map;
my @array = (1..5);
my @other = (4..12);
$map.insert(@array => 1);
$map.get(@other); # Returns 1 !!!
Whatever the array equality operator is, it sure isn't that! :)
Do you see the problem now? If I use ==, then I get length
comparison. If I use eq, then I get string comparison (which,
depending on the elements' types, may not be correct).
Map was just a coded example of what Hash has to do if it doesn't want
to be keyed by strings (and that option is given in Perl 6).
Luke
