[asdf-devel] The issue at hand

[Robert Brown]

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 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?
>
> Best,
> Robert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20140124/22a3ab32/attachment.html>