22.01.2014, 09:51, "Anton Vodonosov" <[email protected]>: > 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.
I see a problem. Only new compile-op, load-op, load-source-op are inherided from downward-operation, so they would be compatible with the proposed stub (defclass operation (downward-operation) ()) But new test-op inherits only from selfward-operation, without downward-operation. So inheriting it from the stub operation will introduce downward-operation and change test-op semantics. I don't know if that's a stopper the idea.
