james anderson <james.anderson@...> writes:
> please find attached a transcript of a reduced example. the method
> combination is reduced here, relatively, just the site which signaled
> the error in the previous example and the function definition to a
> minimal method complement.
> ? is it possible to suppress this effective method precomputation?
> ? given such a method combination, is there some specific load order
> which is guaranteed to succeed?
Answering these questions properly would require rather more time than I
have at the moment, unfortunately. However, I can suggest a way of
rewriting your method combination to avoid this problem: the body of a
long-form method combination is a bit like a macro, in that it is
responsible for generating code; at the moment, you are generating
errors at "macroexpand" (method-combination) time. Instead, I suggest
that in the erroneous situations you detect at method combination time,
instead of signalling an error directly, you expand into a call to
method-combination-error. Something like (untested):
(&key (operator 'progn) (order :most-specific-first))
((around (:around) :order :most-specific-first)
(control (:control) :order :most-specific-first)
(default (t) :order :most-specific-first)
(variously-qualified * :required t :order :most-specific-last))
"test sbcl and lispworks long form combinations.
both implementations are observed to trigger a method-combination-error
when they attempt to compute an effective methodwhen the very first
method definition is added to the generic function."
(unless (member order '(:most-specific-first :most-specific-last))
`(method-combination-error "Invalid order: ~S" ',order)))
(let ((form nil))
(unless (and control variously-qualified)
`(method-combination-error "no applicable :control method: ~S. ~S"
(setf form `(,operator (call-method ,(first control) ,(rest control))
(call-method ,(first variously-qualified) ,(rest variously-qualified))
(call-method ,(first default) ,(rest default))))
(setf form `(call-method ,(first around)