[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another try on object creation
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Another try on object creation
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 3 Sep 87 14:14 PDT
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Wed, 2 Sep 87 23:13 EDT
- Sender: Bobrow.pa@Xerox.COM
Why don't you use a class prototype to call
default-initargs and check-initargs?
Moon had two arguments for this
One is that this was the only use of prototypes,
so by changing this we can eliminate the
need to expose that concept; it makes the standard simpler.
The concept of class-prototype must be introduced for other reasons in
the metaobject protocol, so I don't buy this reason.
The second reason is ... functions generic on the class are
part of the metaclass protocol and you only write methods for them
if you are doing over part of the implementation.
My intuition (expressed in our initial propposal) was that
default-initargs, check-initargs etc were really user (instance)
business. However, I now agree with Moon that these mechanisms for
initialization (except for user-defined :after methods) are more closely
associated with the implementation of a class and hence are metaclass
methods. Ordinary users would rarely want to change them -- especially
if these methods are not guaranteed to be called each time (i.e.
optimized away) except at some great cost. Since I think these
optimizations are important in the standard case, I am happy to leave
default-initargs and check-initargs specialized on the metaclass.
I do have another question on the initialization proposal though. Why
do we need &method-key? Why not make the congruence rules for generic
functions be those Moon described for &method-key i.e. the acceptable
named arguments for a generic function are the union of the named
arguments of the methods, or &allow-other-keys. The one feature this
eliminates is the ability to define a generic function for which all
methods must have exactly the same named arguments. This seems a small
loss, and we gain by not having to add another lambda-keyword.
Another question. What happens if a method is invoked with a named
argument that it is not prepared to receive? Is it a run-time error?
It is easy to construct examples where this could happen.