Re: Object creation discussion (at last!)

[Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>]

     Date: Fri, 17 Apr 87 14:49 EDT
     From: "David A. Moon" <Moon@scrc-stony-brook.arpa>
     Subject: Re: Object creation discussion (at last!)
     
     
       >> What if multiple initargs that fill the same slot are supplied?
       
       If the same initarg is given more than once in the arguments to make-instance,
       the leftmost occurrence prevails, as required by Common Lisp.
       
       If two different initargs that fill the same slot are given in the arguments
       to make-instance, the leftmost occurrence prevails (alternatively we could
       make this an error, but I think it's simpler to treat it the same as two
       occurrences of the same initarg).
       
       A :constructor option whose lambda-list has more than one parameter that
       fills a single slot signals an error, whether or not the parameter names
       are eq (see proposal below for how it is possible for non-eq parameters
       to fill the same slot).
       
     I also added the following related clarification:
     
       When :default-initargs defaults an initarg that
       fills a slot, it is treated the same as an :initform slot-option for purposes
       of inheritance (note well: the class that specifies the :default-initargs
       may not know whether the initarg fills a slot or not, and indeed this may
       depend on which subclass of that class we are dealing with).  If a single
       class specifies more than one default value for a single slot, via
       :default-initargs or :initform or both, an error is signalled.
     
     Is this agreeable?

Yes.
     
         Initargs don't have to be keywords, but the entire object creation might not work
         very well if any of initargs is not a keyword:
     
         In common Lisp, :allow-other-keys T works only for keyword value pairs. We would
         have to slightly change its meaning for make-instance.
     
     	  In practice this is probably implemented by calling all of the
     	  initialize-instance methods with all of the initargs and automatically adding
     	  &allow-other-keys to the lambda-list in defmethod.
     
         This won't work if there is an initarg which is not a key. The methods that
         can be called during object creation (like those on allocate-instance) would be
         easier to code if they knew that they would get keyword-value pairs. (if I
         understand correctly, those methods would get all the arguments supplied to
         make-instance, right?)
     
     I can't understand what you're getting at here.  Could you send a follow-up
     message this is more explicit?

Take the following example:

(make-instance 'class-1 'SLOT1 2 :AREA 'class-1-area 'JUNK 3
               :allow-other-keys t)

SLOT-1 is an initarg for a slot, :AREA is a key for an allocate-instance
method, but JUNK is not a valid initarg.  According to your proposal,
:allow-other-keys would tell make-instance to ignore JUNK (ie.  return
without signalling an error).  In Common Lisp :allow-other-keys T
does not apply to non-keywords like JUNK.

Suppose I have a method like:
(defmethod allocate-instance ((class 'class-1) &key :area
                               &allow-other-keys)
   .....)

If we call allocate-instance with all the initarg-value pairs coming
from the make-instance call and if all the initargs are keywords, then
according to Common Lisp, only the :area keyword is not ignored and we
get the intended effect.
Now, if one of the initargs is not a keyword, then Common Lisp says it
is an error... 
My point is, the implementations will have to filter out non keyword
initargs that are not relevant to allocate-instance before calling
allocate-instance if they want strict compliance with CLtL.  Is this
true or did I miss something?


       >> Can step 2 return an existing object instead of allocating storage,
       aborting the remaining steps?
       
       Step 2 can return anything it wants, but the remaining steps are still
       executed.  To do "interning" you must build a higher-level interface around
       make-instance; make-instance always makes.  No way is provided for the
       metaclass to be able to completely bypass the entire action of MAKE-INSTANCE.
     
     Is this agreeable?
Yes.