Anton Vodonosov wrote:
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?
I am willing to do so. Faré is really the one who needs to judge this. See my remarks below.
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
I think if we were to do this, we would need to add a BASIC-OPERATION that would sit above the other operations and that would serve half of the purpose of the current OPERATION (providing a common root for all of the classes). I think the danger is that existing methods that dispatch on OPERATION, intending to affect *all* operations would now be broken. They would have to be moved to BASIC-OPERATION. Repairing that might involve modifying more code than the current solution.
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.
I believe that to be correct. The only examples of TEST-OP that I know of involves a test system, with files that define tests according to some library, and a PERFORM method on TEST-OP at the system level that invokes some function in the test framework (e.g., fiveam:run!) to run the tests that the component files have defined. When I say "I believe that to be correct," credit is due to Faré for thinking this true and convincing me that SELFWARD is correct and DOWNWARD is not correct.
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.
I believe that the way the existing code for TEST-OP was made to work in the presence of downward dependency propagation was to define no-op methods something like this: (defmethod perform ((op test-op) c) (values)) so that when dependencies were propagated down to individual files, they would do nothing. Your solution 2 would preserve these.
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
I would prefer, in order, your solution 1, 2, 3.