[asdf-devel] Pushed version 3.1.0.52 -- first version with checks for OPERATION subclasses -- please test!

[Faré]

On Tue, Jan 21, 2014 at 8:45 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
>>> FWIW, *all* the OPERATION-redefining systems will be broken.  This is intentional.  All such systems need reexamination, and potentially patching.
>>
For the record, I still think this intentional breakage is a bad idea.
In the short term, it causes a known inconvenience
for users of existing software.
In the long run, it introduces a new class of dubious value
without MOP enforcement
(and MOP enforcement might or might not be achievabe portably,
even after importing a good chunk of closer-mop).
All that for the sake of hypothetical software
by people who have been wilfully out of the conversation for over a year.

>> Have you considered leaving old asdf:operation as a deprecated backward compatibility stub defined as
>>
>>   (defclass operation (downward-operation) ())
>>
>> And the hierarchy base class will be called for example base-operation:
>>
>>   (defclass base-operation ()    )
>
> I did consider this, and Fare indicated that this was not an acceptable alternative.  I believe the upgrading might be quite awkward if we did this (although he can speak to this more clearly).  We also considered trying to trap the definition of OPERATION subclasses, but Pascal Costanza, who I believe to be the leading expert on practical use of the MOP, indicated that would be impractical.
>
Well, that would break some non-trivial amount of code
that defines methods specialized on OPERATION and assumes
that's the base of the hierarchy so the method works on everything.
And that code is somewhat harder to automatically detect at runtime.

But the current patch also breaks code, so, oh well.


> The current expedient is a way to "fail loud," since we have no way of reliably detecting only the cases that need fixing.
>
> However, I can speak to the difficulty of identifying the need to revise these definitions based on personal experience at SIFT.  The failures that you get from missing dependencies like this can be *very* difficult to trace back to the ASDF change.  In our case, the only visible error was in a bash script that post-processed the results of a user-defined OPERATION!  Indeed, the people directly encountering the bug didn't even know to look at TRAVERSE, much less could they figure out the need to revise an ASDF system definition.

Would that patch have caught your issue at SIFT?

PS: I used to avoid committing spaces at end of line.
I see that you have some.


PPS: Anton reports no error. Is that because the classes that are
broken are never invoked during the loading of those libraries, only
during the using of them, but no code in quicklisp actually uses them?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Fraud is the homage that force pays to reason.  — Charles Curtis