[asdf-devel] The issue at hand

Pascal Costanza pc at p-cos.net
Sun Jan 26 01:36:36 UTC 2014

On 25 Jan 2014, at 23:29, Faré <fahree at gmail.com> 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.

You have to be careful: If anybody defines :around methods, you will get surprising results. This is why the CLOS MOP forbids user code to define methods on pre-defined metaclasses, where a very similar trick is used to bottom out the reflective tower - specified generic functions on standard-xyz classes test whether the class of the metaobject parameter is exactly standard-xyz or a subclass, and branch accordingly. You may want to specify similar restrictions on user code to prevent such surprises.

I also strongly advise against turning warnings into cerror or error. It just prevents working code from continuing to work, which is gratuitous IMHO.


Pascal Costanza
The views expressed in this email are my own, and not those of my employer.

More information about the asdf-devel mailing list