Daniel Herring wrote:
Would it be possible for your test to inject the old default behavior into such classes?
I'm not thinking of any clean CLOS or MOP tricks, but a direct implementation might not be too hard.
For example, add an API-VERSION field to the OPERATION class. By default, it will be uninitialized, signifying :asdf2 behavior. New subclasses could explicitly set it to :asdf3. The mixins or a variant of the subclass test might also set it to :asdf3. Then the dependency traversal code could maintain a check for this field along with the new mixins.
So the idea would be that instead of signaling an error, we would check for API-VERSION :asdf3 and if we don't apply it, we would do something like
(change-class obj 'BACKWARDS-COMPATIBLE-OPERATION)
?
where we have
(defclass backwards-compatible-operation (sideway-operation downward-operation selfward-operation) ())
I think that would *almost* work. We'd have to tweak the way SELFWARD-OPERATION is used, but that should be feasible.
We could even do that using the existing superclass check (backpatch unless we find one of the new OPERATION subclasses as parent), rather than having to introduce API-VERSION.
I am open to further discussion of this option.
best, r