[asdf-devel] The issue at hand

[Robert P. Goldman]

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