22.01.2014, 20:11, "Robert P. Goldman" <rpgoldman@sift.info>:
Unfortunately, I don't see such a solution on the horizon: Pascal has demonstrated to my satisfaction that we cannot trap the *definition* of new OPERATION subclasses, only their instantiation. Faré has similarly ruled out deprecating OPERATION itself.
I don't think that preserving OPERATION semantics is really ruled out. Lets consider it a little bit more? Is it true that old ASDF:OPERATION is semantically equivalent to the new DOWNWARD-OPERATION? If yes, the proposal I made earlier looks appropriate: OPERATION inherit from DOWNWARD-OPERATION COMPILE-OP inherit from OPERATION LOAD-OP inherit from OPERATION LOAD-SOURCE-OP inherit from OPERATION If we make so, these operations are backward compatible and at the same time fit the new ASDF 3 design. The only relatively small issue we have is with TEST-OP. ASDF 3 wants TEST-OP to be just SELFWARD-OPERATION, while previous semantics of TEST-OP was inherited from old OPERATION, i.e. equal to the new DOWNWARD-OPERATION. I think it is a small issue and there are number of ways solving it: 1. Make TEST-OP just SELFWARD-OPERATION, thus breaking compatibility, but only for the code depending which rely on TEST-OP to have downward semantics. It is a smaller compatibility break than breaking any OPERATION-extending code. Probably there is no code at all which relies on TEST-OP being downward. 2. Accept that new TEST-OP is a DOWNWARD-OPERATION - maybe it compromises new ASDF 3 design a bit, but we are fully backward compatible. 3. Do with TEST-OP the same I propose for OPERATION - make it a backward compatibility stub, a DOWNWARD-OPERATION, but also introduce new ASDF3:TEST-OP which is a SELFWARD-OPERATION