[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions on new CLOS document
- To: CommonLoops.pa@Xerox.COM
- Subject: Questions on new CLOS document
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Sat, 13 Feb 88 22:33 EST
- Cc: fahlman@C.CS.CMU.EDU
- Redistributed: CommonLoops.pa
- Sender: FAHLMAN@C.CS.CMU.EDU
[ This may not be the right place for queries about the draft CLOS spec
itself. Is there a better place to send these? I think that the answer
to some of these questions might be of interest to most current PCL
I was looking over the draft CLOS spec (my copy says Feb 4 on it), and I
have a couple of questions. I'm sure I'll have a lot more questions
once I get deeper into this. Anyway...
It appears that one can no longer do something like
(defclass foo ()
(setq inst (make-instance 'foo :a 1 :b 2))
As I read the document, you have to explicitly supply :a and :b as
:initarg options in the defclass call if you want to be able to
initialize them in Make-Instance. Is that true? I can see the reason
for wanting the general initarg mechanism, but was it really necessary
to flush the convenient default?
I notice that in the new With-Slots call, there is no longer any way to
explicitly specify the class to which the instance in question belongs.
I note also that With-Slots now is defined as expanding into a bunch of
Slot-Value calls. Presumably if you use this form within a method that
specifies the class of the instance, you can reasonably expect these
Slot-Value calls to produce efficient inline access forms. But what
about the case where With-Slots is used somewhere other than in a
method? Will those access forms be grossly inefficient because they had
to be compiled with no knowledge of the class to which the instance
belongs? Is there some way for the user to declare this, or do you just
have to avoid with-slots when you're not inside a method?
I'd be interested in seeing a brief description of which forms can be
reasonably efficient and which are inherently inefficient in the new
CLOS (and also in the current PCL).