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

[Pascal Costanza]

On 6 Feb 2013, at 20:36, Faré <fahree at gmail.com> wrote:

> On Wed, Feb 6, 2013 at 8:16 PM, Pascal Costanza <pc at p-cos.net> wrote:
>> Just a question for understanding this better: CLOS provides clean ways to update methods with newer versions. Why do you use fmakunbound instead? Is this to stay backwards-compatible? Would it be a good idea to switch to a CLOS-based solution in the future to prevent such problems?
>> 
>> I'm probably missing something…
>> 
> 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.

Why not keep functions generic if your intent is to redefine functionality at runtime?

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

> 3- CLOS is yet another vast source of portability issues,
> that I don't want to open.
> And for ASDF, I can't rely on an external library such as closer2mop
> (although, maybe now I can?).

CLOS is part of ANSI CL, and in that regard not more or less well specified than the rest of Common Lisp. The quality of the CLOS MOP specification is indeed lower, but so far none of the things you seem to want seem to require CLOS MOP functionality, so I'm not sure how relevant this is.

find-method and remove-method are part of CLOS, no MOP required. In many cases, a plain defmethod is sufficient, even for 'removing' methods (just use an empty method body).


Pascal


--
Pascal Costanza