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