Re: [CLOS] Ensuring a method exists

Pascal Costanza <pc@xxxxxxxxx> writes:

Rahul Jain wrote:
Equality is not an OO concept. You should not be using a g-f to
determine equality.

Says who?

Says me. ;)

But seriously. Equality is not just inherited. Note that I qualified my
use of OO below. It's fine to compare objects, just not in a way that
gets inherited by subclasses.

What would it mean for me to compare a point to a
color-point? And I mean OO in the polymorphic sense, not the
encapsulation sense.

Comparing a point to a color-point could have different meanings
depending on context. I can imagine situations in which a default color
is assumed for non-color points. I can also imagine situations in which
the color is simply ignored. Even throwing a dedicated exception can be
a well-defined behavior, especially with the condition handling system
in CL.

Right, I tried to make that point before when I described what _I_ would
expect a point= function to do. Of course, all such discussions are
mental masturbation because what really matters is what a specific
application wants to compare. But I don't see how that implies that g-fs
are the way to implement such (a) function(s). In fact, I would think
that it would indicate that g-fs are the wrong way to do it because it
implies that such operators can be arbitrarily augmented by other
libraries. This may not result in expected behavior in all applications.

There's a reason why the equality operators in CL are not g-fs.

The equality operators in CL are generic in the sense that they are
applicable for several types. You just can't define methods on them (and
even that is not a given, since the CL spec allows implementations to
provide all plain functions as CLOS generic functions).

Right. I don't like equal or equalp for that exact reason. They're just
a mishmash of other equality operators on specific types. There's no
reason that specific combination should be preferred over any other. I
consider them to be historical artifacts.

--
Rahul Jain
rjain@xxxxxxxx
Professional Software Developer, Amateur Quantum Mechanicist
.

Relevant Pages

  • Re: collection framework: using the good interface
    ... The word object's class would implement Comparable, and should have equals and hashCode consistent with compareTo, but I would not make two words equal unless they are, in all respects, the same word. ... I'm more and more convinced that equality should involve all aspects of the Word class, but I'm still uncomfortable with mixing lexicographic information (allowing to compare objects in different collections) and information about frequency, distribution, cooccurrents. ...
    (comp.lang.java.help)
  • Re: If statement
    ... i want to compare atabsin equality ... or call the function atabs passing in the argument i ... since that value is *not* non-zero, ...
    (comp.soft-sys.matlab)
  • Re: [CLOS] Ensuring a method exists
    ... application wants to compare. ... I said "depending on context" for a reason: I think something like dynamically scoped functions or ContextL can be of use here. ... The equality operators in CL are generic in the sense that they are ...
    (comp.lang.lisp)
  • Re: Glasgow haskell vs. Lispworks
    ... 'dbenson AT eecs DOT wsu DOT edu' wrote: ... Jon simply has been using the object identity instead of value ... The equality on objects is said to be object ... This is useful to compare ...
    (comp.lang.functional)
  • Re: Why keep identity-based equality comparison?
    ... >> equality operator for Py3K, ... Ditto for container methods that ... Whenever you compare two objects that ... > don't have the same type, you'll get an exception and terminate the ...
    (comp.lang.python)