[armedbear-devel] default-initargs not respected for funcallable-standard-class

[Pascal Costanza]

On 30 Dec 2012, at 18:11, Rudolf Schlatte <rudi at constantly.at> wrote:

> 
> On Dec 9, 2012, at 17:07, Pascal Costanza <pc at p-cos.net> wrote:
> 
>> Hi,
>> 
>> What the subject line says. Here is a test case:
> [...]
> 
> Thanks, this should be fixed in r14344.


OK, this looks pretty good. More and more of my tests succeed.

I am now running into an issue which is admittedly not a bug in the strict sense, but I would encourage you to consider changing the existing behavior anyway: In ensure-generic-function-using-class, abcl is making a few sanity checks and issuing errors, and it is correct to do so according to the HyperSpec. However, since they are done already at such an early stage, some useful MOP idioms are not easily expressible, or at least need to be expressed differently, and I think it would be better to perform the checks at a later stage, for example inside shared-initialize.

The concrete case that I encounter is the :lambda-list initialization parameter. In AspectL and filtered-functions, I need to be able to modify the lambda list internally, by adding one or two extra required parameters. I do this, extremely roughly, as follows:

(defmethod initialize-instance :around ((gf my-generic-function) &rest initargs &key lambda-list)
  (apply #'call-next-method gf
         :lambda-list (list* extra-parameters… lambda-list)
         initargs))

All methods that are added to such generic functions also get the extra parameters padded in during method metaobject initialization. However, due to this, the lambda list that ensure-generic-function-using-class sees is, by definition, not congruent with potentially existing methods, and thus complains about this fact with an error. If the check would only occur later (for example in shared-initialize on standard-generic-function), then the modifications would correctly pass through. At least, that is the case in all the other MOP implementations in which AspectL and filtered-functions work.

Again, nothing in the HyperSpec and the CLOS MOP specifications specify where the checks must take place, so you can rightfully choose to keep things as they are. I would then have to change AspectL and filtered-functions to modify the lambda list in an around method on ensure-generic-function-using-class (which would not be 100% portable, though).

What are your thoughts on this?


Best,
Pascal

P.S.: All the best for 2013!!!

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