Re: Reinitialization

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

        From: Danny Bobrow <Bobrow.pa@Xerox.COM>
          (unless (check-keyword-arguments
    		(cons (class-prototype class) initargs)
    		(list #'allocate-instance
    		      #'initialize-instance
    		      #'initialize-new-instance)
    		(class-slot-initargs class))
    	 (error "illegal initarg"))

    But this doesn't work because each one of allocate-instance,
    initialize-instance, and initialize-new-instance takes slightly
    different arguments.

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
way).

2) Change the argument structure for  check-keyword-arguments

check-keyword-arguments required-arguments
                        key-word-arguments
                        generic-functions
                        &optional extra-allowed-keywords

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).


(defmethod keywords-for-applicable-methods 
   ((g-fn standard-generic-function)
    required-arguments)
  ;; 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.

Ideas? Comments?