> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: "Dave Whipp" <[EMAIL PROTECTED]>
> Date: Wed, 11 Dec 2002 14:54:18 -0800
> Organization: Fast-Chip inc.
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Newsreader: Microsoft Outlook Express 5.50.4920.2300
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300
> X-Posted-By: 64.161.209.178
> 
> "Michael Lazzaro" <[EMAIL PROTECTED]> wrote:
> > After thinking about it a little more, I'll set myself on the "yes"
> > side.  And propose either '===' or ':=:' to do it.
> 
> Definitely '==='.
> 
> This is used in various other languages.
> 
> > >    $obj1 eq $obj2;    # [1] are their stringifications identical?
> > >    $obj1 == $obj2;    # [2] are their numifications identical?
> > >    $obj1 === $obj2;   # [3] are they in fact the same object?
> >
> > The reason being that you could in fact want to say any of [1], [2],
> > and [3] as separate, useful concepts.  So merely overloading '==' or
> > 'eq' would not be sufficient, as it would hide the previous, still
> > useful meanings.
> 
> There's actually a fourth concept: two (different) objects represent
> the same value. (Actually, its the generalization of [1] and [2]).

So do "0123" and "123" represent the same value?  Sometimes.
 
> Unfortunately, this concept gets fuzzy because there may be multiple
> equivalence classes that define different values of same-ness for a
> given pair of objects. As a trivial example, consider the equivalence
> class of case insensitivity, applied to strings. The current way of
> defining this is to say:
> 
>   ($a.lc eq $b.lc) # assuming lc is a member, not a sub
> 
> But this requires us to create two new strings before we can
> compare them. Whilst there might be optimizations for special
> cases, the general problem remains: its not nice to define
> equivalence classes as conversions to strings/numbers.
> 
> Another way of expressing the above example, is:
> 
>   $a.compare_case_insensitive($b)
> or
>   compare_case_insensitive($a, $b)
> 
> This is a general solution, but it seems a bit heavyweight for
> many/most specific cases.

In general, there is no, um, general solution.  Another equivalence
class is whether two strings are equal when you change there first
character to 'R'.  "cat" and "hat" share this.  But you wouldn't want
a method for it.

> It seems to me that most objects/classes have a default
> definition of sameness. For this, it'd be nice to use a
> simple operator (e.g. '==' or  'eq') If I defined
> 
>    my Str $a is CaseInsensitive = "hELLO";
> 
> then I would like C< $a eq "Hello" > to DWIM.

    class CaseInsensitiveString is Str;
    sub operator:eq (CaseInsensitiveString $a, Str $b) {
      lc $a eq lc $b
    }
    sub operator:eq (Str $a, CaseInsensitiveString $b) {
      $b eq $a
    }

(Technical detail:  What would $a eq $b choose if both $a and $b are
C<CaseInsensitiveString>s, as both methods are equidistant from that
expression?)

> Can this be applied to other objects? If I have a class named
> PostalAddress, then I'd expect to compare them as addresses,
> not as strings. Instead of
> 
>   $a.canonical_value eq $b.canonical_value.
> 
> I just want to use C<eq> (or, if you insist, a new operator
> that currently has no name).

Sure.  Just overload it.  That's what overloading is for.

> 
> Sameness is probably a more common operator then identical-ness
> (I use the latter frequently: but I write a lot of code for testing and
> debugging -- its my job). So perhaps the C<===> operator could
> be used for comparison under the default equivalence-class of the
> operands. I'd find it unintuitive, but I'm could get used to it.

I'm in favor of just using $a.id == $b.id.  But the idea of === was to
override what the object thought of as equal, and find out whether it
is precisely the same object.

Luke

Reply via email to