[asdf-devel] Tests completed

[Faré]

>> The big problem, however, in this case, is still how do you
>> distinguish between a "good" class that shouldn't trigger a warning,
>> and a "bad" class that should.
>
> By deprecating the use of operation as a superclass, and providing a new ‘new-operation class (or some such) that user code has to use instead. (new-operation could be a subclass of operation…)
>
I'm not sure this helps at all:
* For code going forward, that could be a signalling mechanism — but
going forward, whichever way we do it is easy, since people who today
are hacking for ASDF2 and not ASDF3 are responsible for their own
problems, really.
* For existing code, it doesn't help, since that code already exists,
and the problem is precisely to distinguish between the good code and
the bad code if any is left.
* As a general versioning mechanism, I don't think that introducing
operation-v3, operation-v4, operation-v5 is a good way to distinguish
between good and bad code as we evolve the hierarchy, especially since
actual code will likely already inherit from one of the subclasses, in
which case it automatically gets the new superclass, which then can't
be used as a reliable discriminating criterion.

The thing is, CLOS simply doesn't have any standardized mechanism to
deal with code versioning, though it does provide the low-level hooks
to deal with data upgrade, and you can probably build your versioning
system on top of it. I'd love it if there were a mechanism, and if
ASDF could use it, and/or be a platform to discover it. But in the
meantime, we shouldn't expect ASDF to do more than is possible. ASDF
is always doing so much more than most software in terms of static and
dynamic version compatibility and upgrade!

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"To alcohol! The cause of... and solution to all of life's problems!"
        — Homer Simpson, quoted by H. Duray about Addiction to Government