[asdf-devel] The issue at hand
robert.brown at gmail.com
Fri Jan 24 16:49:35 UTC 2014
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?
On Fri, Jan 24, 2014 at 11:23 AM, Robert Goldman <rpgoldman at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the asdf-devel