[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!

[Anton Vodonosov]

22.01.2014, 20:11, "Robert P. Goldman" <rpgoldman at 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