Re: Alternative to compute-discriminating-function protocol

[Gregor J. Kiczales <gregor@parc.xerox.com>]

Actually, this is part of a long-standing discussion we have been having
here about ways to provide increased support for user extensions that
use non-class specializers.  One way of looking at this is how might the
protocol be extended to make it easier for a user to implement EQL
specializers if they weren't already there.  Unfortunately, there aren't
any examples of non-class specializers that work as well as EQL.

I think the reason Danny didn't include this rationale is that he may
have intended only to send this to those of us who have been working
with this issue.  I can't say for sure of course!

This proposal, as we have noticed in discussion here this morning,
doesn't really provide any more power than the mechanism that is already
written up.

Basically, the idea in this mechanism is that you can defer some of the
method applicability testing to the body of the effective method.  This
is done by doing something like putting a discrimination net in the
effective method.  Unfortunately, as is demonstrated in the current PCL,
discrimination nets like this don't work very well, and they scale even
less well.

Using the protocol already written up, the same thing can be achieved by
a conspiracy of compute-effective-method, compute-applicable-methods,
and compute-applicable-methods-using-classes.  compute---using-classes
simply returns the extra methods and then compute-effective-method adds
the extra discrimination code to the effective method.  This is
essentially equivalent to the mechanism in Danny's message.  The extra
two things he mentioned are the method-arg lexical function, for which
the :arguments option can be used, and flush-cacheable-methods which
should can be done by recomputing the discriminating function.

My personal opinion is that there is a pretty important piece of work to
be done here, addressing one of the big problems with current OO
languages.  Specifically, figuring out the difference between the
class-based discrimination most OOPLs support and other kinds of
discrimination (like on the value in a slot) that we do with some
explicit conditional construct.  We all know the frustration of having
to decide whether, for a given property of an object, we are going to
encode it in its class or in the value of slot.  Working this out would
get a new kind of integration of OOP and existing language constructs.
Once it gets worked out, one could imagine extending the MOP to support
it.  I don't expect that will happen in the near future.

But, we keep discussing it.  What would life be if we stopped thinking
up new problems for ourselves :-)