[asdf-devel] The issue at hand

Daniel Herring dherring at tentpost.com
Fri Jan 24 05:21:22 UTC 2014

On Thu, 23 Jan 2014, Robert P. Goldman wrote:

> Fare has had to change the semantics of the OPERATION class. Previously, 
> the OPERATION class would automatically trigger dependencies downward, 
> ... "leftward," and onto itself ("selfward").
> In order to preserve the integrity of the code, OPERATION remained as
> the superclass of all operation objects.  But its semantics has changed.
> For those cases, I have pushed a change that checks to make sure that
> all operations that are instantiated are subclasses of either
> test fails, an error will be signaled and the programmer will have to
> fix the offending OPERATION subclass's definition.

Backwards compatibility is a really important goal for low-level 
infrastructure.  It provides the stability needed for others to trust 
building on a framework.  While the proposed changes do affect a minority 
of the userbase, they do "punish" past efforts to use the advanced API 

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.

If we are unable to find a transparent solution, then a secondary goal is 
to find a solution that allows new libraries the option to support both 
the old and new ASDF semantics.  Since ASDF can upgrade in-place, I 
believe this rules out reader conditionals.  Does ASDF have a hook API 
that notifies libraries of the possible need to re-initialize their ASDF 
extensions when it reloads?


More information about the asdf-devel mailing list