[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Object Creation Discussion (at last!)
- To: kempf%hplabsc@hplabs.HP.COM
- Subject: Re: Object Creation Discussion (at last!)
- From: Gregor.pa@Xerox.COM
- Date: 23 Apr 87 18:24 PDT
- Cc: email@example.com
- In-reply-to: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>'s message of Thu, 23 Apr 87 08:03:20 pst
Date: Thu, 23 Apr 87 08:03:20 pst From: Jim Kempf
From subsequent discussion, it seems as if an additional
DEFCLASS option, :DEFAULT-INITARGS is being proposed. I wonder if
this is needed, considering that a user can already specify an
initialization value via the :INITFORM option? Perhaps the
metaclass ought to attend to this? Or the :INITFORM and
:DEFAULT-INITARGS options should be merged?
I don't think we have reduced initialization to its fundamental
components yet. In this message I am trying to attack some of our
assumptions to see if that can help us get at those fundamental
What if we got rid of :initform??
What is the purpose of :initform anymore? You only need it when you
want to specify the default value for a slot that isn't set by any
initarg. This means that we have two mechanisms which do almost the
same thing -- initargs which set slots are almost a superset of
initforms. This is a sure sign of bad modularity.
Let's just pretend you didn't have initforms but that you did want to be
able to have some slots which had "default values" but which weren't
initable from the initargs passed to make-instance.
(in the terminology of all previous proposals:
(defclass position () ((x 0) (y 0)))
now, adopting a slighlty different syntax for :default-initargs, you
(defclass position ()
(:default-initargs (:moosefish1 0 x)
(:moosefish2 0 y)))
(apologies to Alan Snyder)
This new syntax for default-initargs reads:
":moosefish1 is an initarg whose default value is 0 and which
uses to set the value of the x slot..."
:moosefish1 is some name which is chosen to be weird enough that no-one
will ever use it. So, "in-effect" the slots are not initable in the
call to make-instance. When the initialize-instance generic-function is
called (whether that call is open coded or not) the values of the x and
y slots are sure to be 0.
:moosefish1 is silly of course (more apologies to Alan), but what about
(defclass position ()
(:default-initargs (nil 0 x)
(nil 0 y)))
What I am trying to do is seperate what I perceive as the separate parts
of what is going on into separate places.
1. the structure of the instance is specified, the slots and their
2. the legal initarg names are specified
3. the default values for the initargs are specified
4. automatic initialization of the values of some of the slots by
make instance is specified.
the slot descriptions specify 1 (the structure of the instance)
the cars of the :default-initargs option arguments specify the legal
the cadrs specify the default value
the caddrs specify which slots are set from the value.
think of the :default-initargs syntax as being something like the syntax
of what follows &key in a lambda list except reversed, so each can be
initarg | (initarg default-value) | (initarg default-value slot-name)