[asdf-devel] Tests completed

[Robert P. Goldman]

Faré wrote:
>> I would like to do the following:
>>
>> 1.  Add warnings as appropriate wrt changes in OPERATION hierarchy for
>> code that extends OPERATION classes.
>>
> Not sure what you mean by "add warnings": issue an official
> declaration warning people that code may break? Using the MOP to
> detect code that uses defclass with operation as a superclass and
> issue warnings? I mean, all known existing code has been fixed by now,
> or never tested.

Find cases where people define new OPERATION subclasses and issue a
warning about the changes.

The problem is that the current change in implementation breaks unknown
code in ways that quietly cause it to fail to do what the programmer
expects without any visible notification of the change.

Programmers who do not follow ASDF-DEVEL carefully will be completely
blindsided by this change.

Indeed, *I* was blindsided by this change, and I do read ASDF-DEVEL.

I need to look into a means to identify these problematic cases.  Ugh.
MOP not standardized.  Ugh ugh ugh ugh.  I'll see if I can pilfer code
from Closer-MOP to render ENSURE-CLASS accessible.

Is this the moral of this story: code that wishes to be backwards
compatible and portable can NEVER change the class hierarchy above an
API-visible class, because there is no *portable* way to detect when
someone's code will be affected.

> 
>> 2.  Add warnings for people using ABCL or ECL + bundle-op on Mac OS.
>>
> The ABCL and ECL bugs... well, I'm not sure these configurations ever
> worked, so it's no regression. But yes, it should be easy to detect
> such a situation and issue a warning of a cerror might help the user
> diagnose why his code is failing, e.g. in the failing perform method,
> before the failure.

I believe so, and while waiting for a fix, we can allow programmers to
live dangerously by pushing something like :asdf-try-broken-bundle-op
onto *FEATURES*.

This should be easy to add.

cheers,
r