Faré wrote:
I would like to do the following:
- 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.
- 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