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

[Faré]

[Regarding TEST-OP]

>> 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.
>
Note that this is exactly what ASDF3 is doing right now.

>> 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.
>
Also note that ASDF2's TEST-OP used to also have the behavior
of SIDEWAY-OPERATION, whereas ASDF3's TEST-OP does not.

I don't think anyone actively relied on that behavior,
and I know many people (including at work) who actively resented it,
and that was one more reason not to use TEST-OP for testing at work.

Also note that it's trivial to define a MONOLITHIC-TEST-OP
(or however you'd call it) that recurses SIDEWAY.
But if we make the SIDEWAY behavior the default,
it's impossible to derive the non-propagating variant from it
without breaking the barrier of planning abstraction
(by e.g. having the PERFORM method on NON-PROPAGATING-TEST-OP
do an ugly switcheroo).


>> 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.
>
So would I. Big advantage: nothing to do.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Multiple instances of a same hacker with different context in his mental
cache count as multiple hackers wrt documentation and testing needs.