Re: [CLOS] Ensuring a method exists

Ken Tilton <kentilton@xxxxxxxxx> writes:

Christophe Rhodes wrote:
To take a concrete example, consider implementing a data structure
such as an R-tree, which has a relatively complex set of invariants
that you might want to assert are true at various points in the
protocol. Then you implement a variant, such as the R*-tree, which
obeys the same protocol, and indeed shares much of the implementation,
but has slightly different (but overlapping) invariants. How do you
model that, with just CLOS? Probably what you do is define some kind
of abstract base class and make R-trees and R*-trees inherit from that
base class, but now you can't share the methods that actually should
be shared:

Oh. Why not? Don't see that from the set-up above. And, whatever it
is, multiple-inheritance won't help?

Sure, it will (or it can be made to), but part of the constraints that
I am assuming is that you want your class hierarchy to correspond to
your conception of the problem, rather than having to change how you
think about the problem to fit into one particular version of an
object system. If you're not interested in talking about that, then
that's fine.

The reason I say you "can't" share the methods (which is too strong in
the general case, but is what I meant given the constraints of wanting
to use CLOS to express my problem rather than adapt my problem to
CLOS) is that neither
(defmethod foo ((tree spatial-tree)) ...)
nor
(defmethod foo ((tree r-tree)) ...)
(defmethod foo ((tree r*-tree)) ...)
is appropriate. The first case is too general: I would need to
document the inner workings so that other derived classes of spatial
tree can know how to be compatible with FOO. The second case is too
specific: there is no way of saying that these should in fact be the
same method. (Neither case is necessarily a problem in practice when
expressed at this simplified scale.)

Multiple inheritance might help to solve this problem if you developed
foo's protocol a bit more: say
(defmethod foo ((tree spatial-tree))
(assert-foo-invariants tree)
...)
and then the invariants issue could be dealt with by doing something
like
(defclass r-tree-invariants-mixin () ())
(defclass r-tree (r-tree-invariants-mixin spatial-tree) ())
(defmethod assert-foo-invariants ((i r-tree-invariants-mixin)) ...)
but what is the mixin / multiple-inheritance buying us? Only the
ability to express what we want by complicating the inheritance of our
classes, where what I am aiming towards is saying that there should
ideally be a way of expressing what we want without having to generate
implementation-only classes.

If not, sounds like classes and the very idea of OO are simply the
wrong hammer for this problem

Whose very idea of OO? Just as Java's or C++'s model of objects is
not the be-all and end-all, which we as CLOS programmers can see from
our vantage point, it is also the case that CLOS's in-built models are
not the be-all and end-all of "OO", and indeed the designers of CLOS
recognized this themselves, allowing for small movements in the design
space of object-oriented programming.

and it might be wiser to byte the bullet and use macrology and the
DSL thing to Just Say What We Mean.

Why is this better than slightly adapting some of the existing
object-oriented system to express the object-oriented concept? I
agree with you in that ...

[...] maybe that is what is going on and the OP is just leveraging CLOS
as a convenient internal tool to the larger API

.... and it may be that your suggestion of ...

[...] going /further/ and hide the CLOS behind some macrology, at
which point the OP can enforce anything they want really really easily

.... is sensible in any case, but ...

(instead of staring at AMOP looking for support for something not
really OO-able).

.... you claim is that it's not really OO-able, but I don't think that
is true, and specifically I don't think it's necessarily bad design to
want to do things that help express how you think about a problem,
even if you have to tweak the language (using established protocols)
to help you achieve that.

* I get a kick out of it when people respond "oh, sure. here ya
go. there's this class foo, see, and this other class bar, and...". :)

You can see a concrete but unpolished version of exactly my problem
case in the spatial-trees system; the paper I referenced gives an
example of extensible GUI widgets, as I said.

Christophe
.