22.01.2014, 09:16, "Faré" <[email protected]>: >>> 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 () ) >> 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. > > Well, that would break some non-trivial amount of code > that defines methods specialized on OPERATION and assumes > that's the base of the hierarchy so the method works on everything. > And that code is somewhat harder to automatically detect at runtime.
You are right. Then how about this: Old code knows only 5 classes operation compile-op -> operation load-op -> operation load-source-op -> operation test-op -> operation Here "->" means "inherits from" If new ASDF will provide operation as a back compatibility stub (defclass operation (downward-operation) ()) and ensure the compile-op, load-op, load-source-op, test-op are all inherited from operation, then the old code assumptions will be satisfied.
