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

[Robert P. Goldman]

Anton Vodonosov wrote:
> 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?

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.