[asdf-devel] Tests completed

[Robert P. Goldman]

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