Re: [Sbcl-devel] sbcl bug: wrong default value for ensure-generic-function's :generic-function-class argument

[Bruno H. <br...@cl...>]

Christophe Rhodes wrote:
> What I meant by "a specification bug" was that I think that the
> default :generic-function-class as specified was a mistake, and that
> things would be better all round if the
> (ensure-generic-function-using-class (generic-function t)) method
> defaulted its :generic-function-class keyword argument from the class
> of the existing generic function, rather than a globally-specified
> default.
> 
> I don't see any value in the global default as specified (by AMOP;
> ANSI does not specify a default), since I would imagine that far and
> away most callers of ensure-generic-function don't actually want to
> change the class of the generic function if it already exists.  This
> means that callers must perform contortions of the above form to get
> hold of the generic function class to pass to ensure-generic-function,
> but, um, to do that, you have to get hold of the generic function
> itself, so why bother calling ensure-generic-function in the first
> place?  (Sure, reinitializing it with different initargs, but you can
> do that with reinitialize-instance).
> 
> So the reason I think that it's a specification bug is that the
> (generic-function t) method on ensure-generic-function-using-class is
> useless, and that the specified default generic-function-class for
> that method is of no benefit.  I would be entirely happy with
> 
> * the default generic-function-class for the (null t) method is
>   standard-generic-function;
> 
> * the default generic-function-class for the (generic-function t)
>   method is the class of the first argument.
> 
> which I think is reasonable since methods do their own keyword
> defaulting anyway.

This is an opinion that can be defended.

There are cases where the lack of a generic-function-class specification
means to use <standard-generic-function> (like DEFGENERIC); there are
cases where the lack of a generic-function-class specification means to
not call CHANGE-CLASS. ENSURE-GENERIC-FUNCTION-USING-CLASS can have the
right default only for one of the two cases; the other one will have to
pass a :generic-function-class argument explicitly.

A counter-argument against your proposal is that

  1) It's not consistent. It bloats the implementation's code by
     limiting the amount of code that can be shared between the
     (<null> <t>) and the (<generic-function> <t>) methods.

  2) If someone was to add a method with signature
     (<funcallable-standard-object> <t>), the default generic-function-class
     would again be a headache.

> I am happy
> (unless there's something I've missed) to argue for this to supersede
> the AMOP description.

Is there work ongoing on producing a revised AMOP? The mailing list
mop-standard-discuss at common-lisp (.) net is silent.

Bruno