Anton Vodonosov wrote: > 22.01.2014, 20:11, "Robert P. Goldman" <[email protected]>: >> 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.
