Re: Allegro and Sbcl disagree on no-primary-method behavior

Jim Newton wrote:
the problem with defining this "stand-in" method would be that now
NEXT-METHOD-P would return TRUE. which would be even more misleading.

The role of :before, :after and :around methods is to augment the behavior of a generic function, and it is assumed that the primary methods do the main job. So for example, :before methods may check preconditions, :after methods may inform other parties that something important has happened, :around methods may cache results to improve performance, and so on. [1] If an :around method "takes over" and doesn't invoke any primary methods anymore, that may not work well with methods provided by other third-party client code, because you're essentially "abusing" the role of :around methods.

That's always the main point with generic functions, that several parties can contribute to the same operation, but in order to make this work well, the different parties have to rely on some conventions. So I think it's a reasonable design choice to issue an error if there is no primary method for an invocation, because this provides a certain level of guaranty that the method definitions are "sane."

And due to define-method-combination, this is not limiting at all, because you can always define your own rules for what should happen under what circumstances. This should even work in simple applications.

If you're the only one contributing to a generic function, then it may be better to use plain functions, because this gives you more control over what happens.


Pascal

[1] You could characterize such things as "non-functional concerns," but I don't like that term too much, so I try to avoid it.

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