Faré wrote:
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.
What if the previous hierarchy was plain buggy?
Then going forward we have to introduce a NEW class to replace the old class.
Yes, that breaks code, but it only breaks code VISIBLY. Redefinition of existing classes breaks code INVISIBLY.
If we had a new name, say OPERATION-CLASS, then everyone would see that their existing code needed modification. Yes, a nuisance.
But I can speak to the fact that code that quietly goes away and does something unexpected or, worse, quietly does not do something expected, is very difficult to debug.
It's particularly bad in ASDF, because people often don't think to look into it (it's like looking for a bug in "make") and because even if you do think to look into it, you may be getting it from your implementation, which may make it difficult to find.
This will be a maintenance principle going forward: no changes to user-extendible classes without renaming.
This suggests a corollary: in order to prevent horrible *internal* update issues, we should split apart user-extensible classes from internal classes.
E.g., it would make sense to have something like INTERNAL-OPERATION and OPERATION be distinct going forward. That naming policy is obviously not tenable for ASDF now -- OPERATION is used everywhere and must remain -- but adding USER-OPERATION might be a plausible step.
That allows us to incompatibly modify the guts of the program while providing a stable, or visibly-broken, API to the user.
Cheers, r