I have not been following every last detail of this conversation, so please forgive me if what I'm about to suggest is a terrible idea.
It appears that Robert is concerned about breaking ASDF files containing code that defines classes that inherit from OPERATION. I have written code like this and had to do some serious searching before I found an example to follow, so I personally believe that such code is rare and not worth worrying too much about breaking.
However, can't we find and fix 95% of the breakage by running "grep 'defclass.*operation' *.asd" on all the Quicklisp libraries? That would find my PROTO-TO-LISP class, which is presumably now broken. In addition to Quicklisp libraries, my Slurp code can check out several hundred other Lisp packages from web repositories. I could run the same check on those.
By the way, regarding my PROTO-TO-LISP class. I want to inherit from DOWNWARD-OPERATION, right?
Bob
On Fri, Jan 24, 2014 at 11:23 AM, Robert Goldman rpgoldman@sift.net wrote:
Well, this should teach me to think more than 2.4 seconds before responding to emails.
I'm afraid my proposed CHANGE-CLASS solution won't work. The problem is that we would be required to change the parent classes of a new OPERATION to remove OPERATION and add BACKWARDS-COMPATIBLE-OPERATION, and this is precisely what Pascal has explained cannot be done portably, or at least not without a very big new body of compatibility code, because of the non-standard nature of the MOP.
So you are suggesting that we modify the traversal code to check for non-updated OPERATION classes, and then replicate a fixed version of the old logic?
I'm willing to entertain this as a suggestion, but it seems to me very likely to involve adding a large layer of cruft to ASDF. The error check involves only 10 lines. It also has the virtue of forcing people to fix their systems, instead of moving responsibility for their continued correct functioning to the shoulders of the not-very-large ASDF team.
Do you see a way around these issues?
Best, Robert