[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

looking for initargs of make-instance

At 11:16 PM 7/4/93 +0000, Christopher J. Vogt wrote:
>In article <poeck-040793172755@wina65.informatik.uni-wuerzburg.de> poeck@informatik.uni-wuerzburg.de (Karsten Poeck) writes:
>>In article <vogtC9MJ8t.941@netcom.com>, vogt@netcom.com (Christopher J.
>>Vogt) wrote:
>>> I'm trying to write a function that will list all of the initargs
>>> that are available when I do a make-instance, and I don't seem to be
>>> able to find them all, maybe it isn't possible?  
>>You should add
>>(function-keywords (find-method #'ccl::window-make-parts
>>                                  nil (list (find-class 'window))
>>                                  nil
>>                                  ))
>>to your function, since initialize-instance ((window window)) calls

MCL has an undocumented function that does exactly what you asked for:

(ccl::class-make-instance-initargs class)
returns a list of the valid initargs for (make-instance class).
The "class" argument can be a class or a symbol naming a class.

>>I don't know why MCL does not complain about these
>>keywords, perhaps there is somewhere a &allow-other-keys clause in
>Actually, I'm interested in the general solution, if there is one.

MCL has an undocumented internal mechanism for specifying which generic
functions get to vote for valid initargs. Its current implementation doesn't
scale very well (an alist mapping a class to a list generic functions):

(ccl::set-aux-init-functions class init-functions)
"class" should be a class or a symbol naming a class.
"init-functions" is a list of generic functions.
Don't include #'make-instance, #'allocate-instance, #'initialize-instance,
or #'shared-initialize in "init-functions". They always get to vote.

>But this brings up another question (I guess I'm really ignorant about
>CLOS).  I expected that when I do:
>   (specializer-direct-methods (find-class 'window))
>one of the mthods listed would be 'ccl::window-make-parts, but
>it is not there.  So now I want to know where it is hiding!?
>Because I am also interested in knowing all applicable methods
>for an instance of a class, and I cannot find this method, although
>it does exists when you do (find-method ...

This works for me as you expected in both MCL 2.0 and MCL 2.0p2.