Re: [CLOS] Ensuring a method exists

Rahul Jain wrote:
Didier Verna <didier@xxxxxxxxxxxxx> writes:

Rahul Jain <rjain@xxxxxxxx> wrote:

You shouldn't be subclassing something if you don't want to get its
functionality as default.
Sorry ? Consider the classic binary method example Point <- ColorPoint with
the point= function. ColorPoint *is* a subclass of Point, and *no*, I don't
want the implementation of point= for Point as the default functionality in
ColorPoint. I want to be sure that there is an implementation of point= for
both classes.

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

Says who?

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.

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).

My library just allows a declaration of what a class conforming to a
protocol should support and a function to test whether it has gotten to that
point after you've loaded all appropriate code.
How much control do you have on the time at which the check is
performed ?

You call it explicitly. Total control. Total responsibility. Of course,
this is necessary in a dynamic lanaguage, because the "validity" of the
code according to some criteria changes as definitons are added,
modified, and removed from the system.

It won't help you with trying to change the way the applicable method
list is computed, tho. It just checks that there exists an applicable
method. It's also not going to inspect the code of each method to make
sure that every time it calls call-next-method, there will be a next
method to call. Not sure I could do that in a way that avoids false
negatives anyway.

You can't, due to Rice's Theorem.


Pascal

--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
.