Faré wrote:
I'm re-running all the tests with ASDF 3.1.0.35. Looking good so far. Please keep testing in view of a release 3.1.1.
I'm interested in a release relatively soon, but I'm not in a rush.
While there are bug fixes waiting to reach our users, I'm quite concerned by the loss of backwards compatibility in systems that defined their own OPERATION subclasses.
As far as I can tell, *all* such systems will break, since the old solution was to subclass OPERATION and the new solution is to subclass DOWNWARD-OPERATION to achieve the same results. *ALL* programmers' locally-defined operation subclasses are now broken by this change.
I have personally seen multiple systems that are broken by this change, and I would like to see some hard thought put into repairing this.
A somewhat drastic solution would be to make the name OPERATION now denote DOWNWARD-OPERATION (which would remain as a canonical name), and rename the common superclass of DOWNWARD-OPERATION and UPWARD-OPERATION to something like ABSTRACT-OPERATION or COMMON-OPERATION.
The current refactoring is quite problematic, since it moves some of the previously-existing characteristics of OPERATION out and into a sub-class that no one has ever heard of before.
Unfortunately, the above solution is not ready for prime-time, either, since if we add COMMON-OPERATION, all programmers' methods that dispatch on OPERATION will break if used with PREPARE-OP. On the one hand, that's probably not a big deal, since no one will have been customizing UPWARD-OPERATIONs, since they haven't existed. On the other hand, programmers who want to write extensions that really are generic to *all* types of operation (e.g., EXPLAIN type methods) would be broken by this proposed repair.
This problem also exposes a HUGE hole in our regression-testing methods: we have nothing that tests extensions to the ASDF protocol.
I also find that OUTPUT-FILES may now be called more eagerly than before, perhaps because of the new PREPARE-OP. I have seen systems (perhaps not well-built systems....) that defined OUTPUT-FILES on an operation, O, in a way that assumed that earlier operations (COMPILE-OP and LOAD-OP) would be called before the OUTPUT-FILES method on O. That actually seems wrong, since OUTPUT-FILES is part of the plan-making part of the ASDF protocol, rather than the plan-execution part, but it *used to work* and given the extremely sketchy information available to users who wish to customize ASDF, such disruptions need to be very gently handled.
Finally, as the responsible party now, I'm not comfortable sending out another release until I have come to understand the new protocol better than I do now. Indeed, it was culpably negligent of me to release the last couple of versions, and I apologize for doing so.