[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Object creation discussion (at last!)
- To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
- Subject: Re: Object creation discussion (at last!)
- From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
- Date: Mon, 20 Apr 87 14:49:05 CDT
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: Msg of Fri, 17 Apr 87 14:49 EDT from "David A. Moon" <Moon@scrc-stony-brook.arpa>
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?
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
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
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
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?