[asdf-devel] The issue at hand

[Pascal Costanza]

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

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