[asdf-devel] The issue at hand

Faré fahree at gmail.com
Sat Jan 25 22:29:51 UTC 2014


> 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.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The ultimate result of shielding men from the effects of folly is
to fill the world with fools. — Herbert Spencer



More information about the asdf-devel mailing list