Re: Object creation discussion (at last!)

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

David,

	    If multiple initargs that fill the same slot are supplied, which value ends up
	    in the slot is indeterminate.  
       
	In what sense do you mean "indeterminate"?  Do you mean "defined to be
	one of those values, but not defined as to which of them", such that it
	would be legal to use a random number generator to decide?
       
       Yes.  "which value" should be "which of those values".  I certainly won't complain
       if someone proposes a determinate action here instead.
                                                                                
We could check, at run time for make-instance that two initargs that fill
the same slot are not getting a value.
For the constructors, we can check at compile time that they don't specify in
their lambda list two initargs filling the same slot. This would be a
restriction for constructors.


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

      >> Can step 2 return an existing object instead of allocating storage,
      aborting the remaining steps?
      
      No, to do "interning" you must build a higher-level interface around
      make-instance.  Make-instance always makes.

I am wondering if you propose to enforce this. What if somebody defines an 
:around method for ALLOCATE-INSTANCE and does not call-next-method but returns 
an interned object instead ? Is it an error?