[asdf-devel] Tests completed

[Pascal Costanza]

On 12 Jan 2014, at 19:57, Robert P. Goldman <rpgoldman at sift.info> wrote:

> 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.

I wouldn’t recommend fiddling with ensure-class or ensure-class-using-class. It’s too hard to specialize methods correctly on those, and their portability across CL implementations is not very good.

If you want to implement checks on subclasses, it’s better to do this in initialize-instance / reinitialize-instance on metaclasses, but this requires that the subclasses also use those metaclasses, which may break other assumptions.

> 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.

The interface a class exposes to its subclasses is an interface like any other, and yes, interface changes may have negative consequences. That’s correct for any kind of interfaces. It can be better to create new interfaces and leave the existing ones untouched if backwards compatibility is a major concern.

Just my 0.02€…


Pascal

--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.