On 5/19/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Ingo Blechschmidt wrote:
> > I wondered what uniq's default comparator should be, =:=?
>
> &infix:<~~>
Woah there. ~~ is a good comparator and all, but it's not the right
one here. ~~ compares an object and a pattern to see if they match.
That makes it the right choice for when and grep. But we're trying to
remove elements that are *the same*, not elements that *match*.
uniq "hello", 13, /\w+/; # "hello", 13 (!)
In fact, I think this brings up a good point. It's one that we've
already addressed, but I think it needs a little revisiting. The
distinction between == and eq is very nice in its place. However, as
projects become bigger and more object oriented, we're working with
objects more than strings and numbers. And yet, eq compares two
objects' stringifications, and == compares their numifications.
Neither of those tests whether the objects are the same.
Larry has called it "equal", but that was when we thought it was just
for generics. I think it's for much more than that: it's for
comparing any two things that aren't specifically strings or numbers,
even if we know what they are. For types with reference semantics, it
ought to behave just like =:=. For types with value semantics, it
ought to give a reasonable value of "same", something like "as long as
you don't look at the addresses, there's nothing you could do to tell
these apart".
And maybe that's what we call =:=. Value types really should behave
as though identical objects are inherently indistinguishable. There
is, of course, the problem of the .id with those. It is, in the
general case, impossible to come up with an id that is the same
between two objects iff they =:= each other. Maybe that's how you get
around the "should" in my second sentence.
So I suppose that's my proposal. Allow, even encourage, overloading
of =:=, but only for value types. I've been thinking that we ought to
provide a standard role for making something a value type. Maybe it
would require definition of =:=.
Luke
