[asdf-devel] Pushed version 220.127.116.11 -- first version with checks for OPERATION subclasses -- please test!
avodonosov at yandex.ru
Wed Jan 22 05:49:42 UTC 2014
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
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.
More information about the asdf-devel