[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!

[Anton Vodonosov]

22.01.2014, 09:16, "Faré" <fare at tunes.org>:
>>>  Have you considered leaving old asdf:operation as a deprecated backward compatibility stub defined as
>>>
>>>    (defclass operation (downward-operation) ())
>>>
>>>  And the hierarchy base class will be called for example base-operation:
>>>
>>>    (defclass base-operation ()    )
>>  I did consider this, and Fare indicated that this was not an acceptable alternative.  I believe the upgrading might be quite awkward if we did this (although he can speak to this more clearly).  We also considered trying to trap the definition of OPERATION subclasses, but Pascal Costanza, who I believe to be the leading expert on practical use of the MOP, indicated that would be impractical.
>
> Well, that would break some non-trivial amount of code
> that defines methods specialized on OPERATION and assumes
> that's the base of the hierarchy so the method works on everything.
> And that code is somewhat harder to automatically detect at runtime.

You are right. Then how about this:

Old code knows only 5 classes

  operation 
  compile-op -> operation 
  load-op -> operation 
  load-source-op -> operation 
  test-op -> operation

Here "->" means "inherits from"

If new ASDF will provide operation as a back compatibility stub 
  (defclass operation (downward-operation) ())
and ensure the compile-op, load-op, load-source-op, test-op are all inherited
from operation, then the old code assumptions will be satisfied.