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