[asdf-devel] The issue at hand

[Anton Vodonosov]

26.01.14, 00:51, "Robert P. Goldman" <rpgoldman at sift.info>":

>  Faré wrote:
>>  On Sat, Jan 25, 2014 at 7:58 AM, Anton Vodonosov <avodonosov at yandex.ru> wrote:
>>>  Theoretically, OPERATION may be the root class and keep the old semantics
>>>  (downward + selfward + other). And subclasses override this semantics
>>>  as they do now: DOWNWARD-PERATION, SELFWARD-OPERATION, etc.
>>>
>>>  This may lead to some code duplication in ASDF.
>>  This sounds like a great transition plan indeed.
>>  Then we could have a warning for now, that would be transformed in an
>>  error in a year,
>>  and migrate to this new setup that detects wrongful combinations,
>>  without forcefully breaking things in the meantime.
>>
>>  Robert, also, in the manual you should advertise #+asdf3.1
>>  non-propagating-operation, or something, because it won't exist
>>  earlier, and we probably want code to keep running with asdf 3.0 until
>>  every implementation has upgraded to 3.1.
>  OK, will do.  I will try to get all of the new operations written up,
>  but I don't believe I will have time until after the 31st (conference
>  deadlines, and end of contract dates mean that the ASDF manual has to
>  wait...).
>
>  I do not yet the proposal.  How can OPERATION keep the old semantics and
>  still be the root?  There are 11 direct subclasses of OPERATION now, and
>  some fan out from there (e.g., a fair sized subgraph under BUNDLE-OP).
>  How is the overriding to be managed?
>
>  Currently, unlike in the proposal ("subclasses override this semantics
>  as they do now"0, subclasses do not override the semantics, do they?  My
>  understanding was that the behavior of the new dependency-propagating
>  classes was strictly additive.  Is that not true?  To make this new
>  proposal work, as I understand it, we have to add *subtractive*, or
>  non-monotonic behavior inheritance.
>
>  Unless I'm missing something, it seems like this new proposal will be
>  much more complex than the current approach, which just involves two
>  checks, and no modifications to core ASDF code.
>
>  I'm happy to see an approach that would provide no breakage, but I'd
>  like to see a more detailed proposal before we proceed.
>
>  thanks,
>  r

I think this may be done without too radical changes.

I suppose the operation behaviour is represented by some generic functions
(probably returning the list of subcumponents to process by the operation,
when invoked on a component). By overriding these functions, a subclass
may tune its behaviour, no matter what superclasses it has. BTW, I am curious
what exactly generic functions 

Each direct subclass of OPERATION should have overriden all necessary methods to behave
according to the subclass purpose (DOWNWARD-OPERATION, SELFWARD-OPERATION, ...)

This may be achieved introduction of an intermedate, unexporded, class between
OPERATION and DOWNWARD-OPERATION, SELFWARD-OPERATION, ...

It may be called NO-OPERATION, for example. This class overrides all the
generic functions in the operation behaviour protocol to work equally to the current OPERATION.

In this case, DOWNWARD-OPERATION and siblings change inheritance from OPERATION to NO-OPERATION;
rest of their code remain unchanged.

Below this level all the inheritance works exactly as now.

What remains it to implemente the old behavious in OPERATION without inheritence
from DOWNWARD-OPERATION and siblings. I don't know ASDF code, maybe some
helper functions need to factored out from DOWNWARD-OPERATION and simblings implementation,
to be reused in OPERATION, probably something will be duplicated, or maybe
some ASDF mechanizm will help (I remember I saw in some .asd file function
in-order-to mentioned; function named like that may probably be helpful).

Best regards,
- Anton