Anton Vodonosov wrote:
22.01.2014, 02:47, "Robert P. Goldman" rpgoldman@sift.info:
Fixes for this error should look something like this:
(defclass my-operation (OPERATION) ...)
should turn into something like
(defclass my-operation (#-asdf3 OPERATION #+asdf3 DOWNWARD-OPERATION) ...)
[...]
FWIW, *all* the OPERATION-redefining systems will be broken. This is intentional. All such systems need reexamination, and potentially patching.
Have you considered leaving old asdf:operation as a deprecated backward compatibility stub defined as
(defclass operation (downward-operation) ())
And the hierarchy base class will be called for example base-operation:
(defclass base-operation () )
(defclass downward-operation (base-operation) ) (defclass upward-operation (base-operation) ) (defclass sideway-operation (base-operation) ) (defclass selfward-operation (base-operation) ) (defclass non-propagating-operation (base-operation) )
Best regards,
- Anton
I did consider this, and Fare indicated that this was not an acceptable alternative. I believe the upgrading might be quite awkward if we did this (although he can speak to this more clearly). We also considered trying to trap the definition of OPERATION subclasses, but Pascal Costanza, who I believe to be the leading expert on practical use of the MOP, indicated that would be impractical.
The current expedient is a way to "fail loud," since we have no way of reliably detecting only the cases that need fixing.
However, I can speak to the difficulty of identifying the need to revise these definitions based on personal experience at SIFT. The failures that you get from missing dependencies like this can be *very* difficult to trace back to the ASDF change. In our case, the only visible error was in a bash script that post-processed the results of a user-defined OPERATION! Indeed, the people directly encountering the bug didn't even know to look at TRAVERSE, much less could they figure out the need to revise an ASDF system definition.
Best, R