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 DOWNWARD-OPERATION, UPWARD-OPERATION, SIDEWAY-OPERATION, SELFWARD-OPERATION, or a new NON-PROPAGATING-OPERATION. If this run-time 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 features...
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?
Later, Daniel