[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
(cons (class-prototype class) initargs)
(error "illegal initarg"))
But this doesn't work because each one of allocate-instance,
initialize-instance, and initialize-new-instance takes slightly
Unfortuntately, right. I have two patches for this, since I think the idea is
good. Both patches have problems. Here are the alternative patches.
1) The difference in arguments is that #'initialize-instance takes a second
required argument, slots-using-initforms. Instead, make slots-using-initforms
be a keyword argument. This implies that callers of make-instance and
reinitialize-instance could specify which slots they wanted filled with a value
computed from initforms. I can think of some uses for this, but it may be
exposed at the wrong level. I don't consider this a strong argument (either
2) Change the argument structure for check-keyword-arguments
Make required arguments be a list that can select the appropriate methods from
each generic funcion. If the list is too short, consider it equivalent to being
filled out with enough nils to be of the right length.
In either case I envision the code for check-keyword-arguments to use
something like keywords-for-applicable-methods (I called this generic function
method-applicable-keywords in Chapter 3).
;; find the list of applicable methods for
;; required arguments given
;; possibly filling out list of required arguments with nils
;; take the union of these keywords
However, there is a problem in using keywords-for-applicable-methods in
check-keyword-arguments. What value does it return if &rest or
&allow-other-keys appears in any method?
If we take Moon's suggestion of returning the symbol &allow-other-keys in this
case, then check-keyword-arguments cannnot use this value, since the default
methods for initialize-instance and allocate-instance have an &rest argument.
If we take my suggestion of including &allow-other-keys in the list of allowable
keyword arguments, then we suffer from what Moon calls the "untasteful but legal
use of &allow-other-keys as a keyword argument." Perhaps we could outlaw that
use as a keyword in CLOS. Perhaps we could use another key -- is either T or
NIL outlawed as a keyword?
In general, where one wants to provide a common set of keyword arguments to a
set of functions, all must accept the keywords of the other functions. We need
some mechanism for knowing the explicitly handled keywords. That was the intent
of my last suggestion.