[asdf-devel] Change in the way ASDF performs a plan? Or :force semantics?

[Faré]

>> Well, remove-method could be used in some cases,
>> but it doesn't by far cover all cases:
>> 1- sometimes, the function signature changed;
>> &key arguments were added (or removed?),
>> a function was made generic that wasn't before,
>> or generic no more that was before.
>> Only fmakunbound can handle these cases.
>
> Adding or removing keyword arguments in methods is not a problem in CLOS.
>
It's not about removing a specific keyword.
It's about adding or removing the &key capability at all.
If you have a previous (defgeneric gf (x y))
then you can't (defmethod gf (x y &key z) ...).

> Why not keep functions generic if your intent is to redefine functionality at runtime?
>
Some functions were once added as simple defuns
before they were made into gf's later.
Other functions were originally added as gf's
but were later made thin defun wrappers around other gfs.
In any case, remove-method just doesn't cut it.
We need fmakunbound if the signature was ever incompatible.

>> 2- sometimes, other methods exist that were installed
>> by asdf extensions that have been invalidated by other reasons
>> (such as classes being updated, etc.)
>> These methods should NOT be preserved, but wholly invalidated,
>> until an updated version of the ASDF extension can themselves be loaded.
>
> I don't understand this use case. Can you give more details?
>
ASDF3 radically enhanced the way operate or component-depends-on works.
Many internals have changed.
If any ASDF extension depended on some old behavior or internal,
it may fail to work spectacularly.
The only *safe* thing in many cases is
to invalidate all methods by all extensions,
and reload a (new updated version of) the extensions that you need.

>> 3- CLOS is yet another vast source of portability issues,
> CLOS is part of ANSI CL [...]
>
I have ported ASDF to 15 different implementations.
Many implementations have subtle bugs in their CLOS implementation,
or "interesting" interpretations of the specification.
I'm not going to write compatibility layers around incorrect behavior
just so I may build further dependencies on "correct" CLOS behavior.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There is joy in work. There is no happiness except in the realization that
we have accomplished something. — Henry Ford