Re: MOP Comments (Repost) - 2 3 4 5a

[kempf%hplabsz@hplabs.HP.COM]

>     3) Classes in the CLOS Kernel

>     There is no slot for the dispatcher code in STANDARD-GENERIC-FUNCTION.
>     Is the idea to have different method dispatch protocols implemented by 
>     specializing STANDARD-GENERIC-FUNCTION, with COMPUTE-DISCRIMINATOR-CODE 
>     returning the specialized code? The problem with this is that, for 
>     optimization purposes, it may be desirable to have the dispatcher on a 
>     STANDARD-GENERIC-FUNCTION instance change. For example, if all the methods 
>     on the generic function only have built-in classes as parameter specializers, 
>     then the dispatcher need not check if the class of the arguments is a user 
>     defined class, since, if it's not a built in class, then an error should be 
>     signalled. This avoids the overhead of checking whether the arguments are
>     of a user defined class. Given the MOP as outlined in the document, the
>     only way this could be achieved is to have a different kind of generic
>     function, and that means that the generic function object would not be
>     EQ before and after a method which has user defined classes in the> 
>     parameter specializer list is added. One way to fix this would be to do a
>     CHANGE-CLASS  on the generic function object, but that seems somehow
>     to be less than optimal, since it seems to be just fixing up the problem
>     afterwards.

> I guess I don't understand this point at all.  I don't see the relation
> between the optimization you mention and the a slot for the
> discriminator code or the class of the generic function.  

You're right, it doesn't have anything to do with this. I think there
are two issues here, one is that I somehow have this picture which says
that the dispatcher code is logically a slot in the generic function,
because it's part of it, but, taking the functional approach, the proper
set of primitives make it irrelevent if the slot is physically there or
not.

The other issue I'll address after your following set of comments.

> It seems to me that the relevant code is:

> (defmethod add-method (..)
>   .. (compute-discriminator-code gf) ..)

> (defmethod remove-method (..)
>   .. (compute-discriminator-code gf) ..)

> (defmethod update-generic-function (..)
>   .. (compute-discriminator-code gf) ..)

> Given that, compute-discriminator-code can produce a piece of
> discriminator code that is optimized in the ways you mentioned.
> Certainly I would expect that the standard method on
> compute-discriminator-code would perform this optimization.

Yes, this will work if the implementor of CLOS implements 
COMPUTE-DISCRIMINATOR-CODE with the optimizations I've outlined, but here's 
another example. A user wants to implement a discrimintor which caches 
and uncaches data before and after a method invocation, if the method 
being invoked references a persistent object. Unless there is some interface for
generating discriminators, the only way to do this is by :BEFORE and
:AFTER methods around COMPUTE-DISCRIMINATOR-CODE, which might have to undo
things done by the primary, if the user wants to continue using the default
STANDARD-GENERIC-FUNCTION. Of course, it would be possible to say that
user accessable MOP hooks are not available at that low a level (which
essentially corresponds to hooks at the level of FUNCALLABLE-INSTANCE-CLASS).
But this example is something which came up in a real application, and
the only solution, if we wanted to continue using the standard generic
function class,  we could find using the current CLOS is to define user
level :BEFORE and :AFTER daemons around *every* method which accesses
a  persistent object. This seems like a less elegent solution than
providing a metaclass hook.

> Extending the defclass and slot options for a class already works.  I
> think the sentence "If there are any syntactic errors in the defclass
> form an error is signalled" is confusing.  All this sentence is saying
> is that it takes the cadr of the defclass form and makes it be the name,
> the caddr and its the supers, the cadddr is the slots and the cddddr is
> the options.  If for some reason it can't do that minimal parsing an
> error is signalled.  

What about slot parsing? Is any error checking done on the options before
calling EXPAND-DEFCLASS?

		jak