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 <rpgold...@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 > >
