🚀 go-pugleaf

In article <9209101712.AA27788@kuwait.lucid> jonl%kuwait@lucid.com (Jon L White) writes:
>
>re: Date: 8 Sep 92 01:09:40 GMT
>    From: lange@lanai.cs.ucla.edu (Trent Lange)
>    Subject: Alternative specializer types
>    . . . 
>    (defmethod foo ((self (and class1-mixin class2-mixin))) ...)
>
>As Danny Bobrow's reply indicated, there are some theoretically very
>interesting directions in which generic-function discrimination can
>be extended, including boolean combinations of classes.  However,
>research into the style suggested by these directions would probably
>have to make some more basic alterations to a Lisp/CLOS system than
>are envisioned in AMOP's published interfaces.
>
>-- JonL --

The interesting thing about this kind of example is that the AMOP
seems to come very close to supporting it, or at least allowing it.
For instance, an appropriate user method on compute-applicable-methods
and compute-applicable-methods-using-classes would seem to allow it.
(Actually writing those methods to allow full boolean combinations of
classes as specializers might be a bit tricky, but it certainly could
be done.)

The "problem" is that although the far-seeing and flexible published
interfaces of the AMOP allow the programmer to do extremely powerful
extensions of this nature, there are sometimes other parts that aren't so
open-ended and which rule out the extensions.  For example, the parts
of the AMOP that explicitly say that "method specializers are class
metaobjects or EQL specializers", thus ruling out alternative types
of method specializers (such as boolean combinations).  If instead the
AMOP said "the standard method specializers are class metaobjects or
EQL specializers, but can be anything the MOP programmer allows", or
something similarly open-ended, then it could be done.

I've noticed these kind of limitations to the standard provided
interfaces in a few different places in the AMOP.  Presumably they
were stated the way they were because nobody thought of alternative
possibilities at the time.  But hopefully the evolving protocol can
leave things more open-ended in general, and where possible say what
the standard implementation provides, rather than saying what things
must be.

- Trent Lange