[asdf-devel] The issue at hand

[Robert P. Goldman]

Faré wrote:
>> 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...).
>>
> Take your time. We're all impatient about it.
> 
>> 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?
>>
> I suppose the trick is as follows:
> 1- move the crucial behavior of downward-operation, sideway-operation,
>   selfward-operation, in separate defun's that are called by the
> respective defmethods.
> 2- have methods on operation that check whether the operation is
>   a subtype of any of the three above or non-propagating-operation.
>   If not — then apply the methods for all of them.
> 3- at instantiation-time, call the same detection function, and issue a WARNING.
>   In six months or a year, it will be replaced by a CERROR, then an ERROR,
>   at which point the defuns can be merged back into the respective defmethods.
> 
> This way, people are warned now already, but ASDF keeps working,
> and we don't break either all the software in quicklisp until later.
> 
> Congratulations to Anton V. for this clever suggestion.
> 
>> 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.
>>
> Yes, the above is essentially emulating non-monotonic behavior inheritance,
> but it needs only rely on typep as introspection mechanism.
> 
>> 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.
>>
> This proposal adds a small bit of complexity, but only local changes,
> and maximally preserves compatibility.
> 
>> 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.
>>
> *If* we have time tomorrow, I could do that live during the walkthrough —
> that could be a good exercise.

If you are satisfied that this can be done cleanly, I am satisfied.

I agree -- congratulations to Anton for a clever solution to a knotty
problem.

Best,
Robert