Re: Another try on object creation

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 2 Sep 87  16:37:17 CDT
    From: Patrick H Dussud <DUSSUD%Jenner%ti-csl.csnet@RELAY.CS.NET>
     
	 (defmethod make-instance ((class standard-class) &rest initargs)
	   (setq initargs (default-initargs class initargs))
	   (check-initargs class initargs)  
	   (let ((instance (apply #'allocate-instance class initargs)))
	     (apply #'initialize-instance instance initargs)
	     instance))

    I have a question: Why don't you use a class prototype to call
    default-initargs and check-initargs?

That's the way the notes from the meeting had it, but in my proposal
I changed that for two reasons.  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 second reason is
a little more complex: in trying to figure out why there was such
apparent randomness, with some functions generic on the instance and
others generic on the class, I decided it must be that functions generic
on the instance can have methods defined by ordinary users, and can
have those methods combined with inheritance, while 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.
At the meeting we said that it was "hard to make default-initargs
and check-initargs generic" and left it at that.  If you think about
check-initargs, all the checking has to be in one place; there is
no way to do it by combining inherited methods, each of which checks
one class's initargs.  In fact there is one method for check-initargs
which looks at the slot-initargs and the lambda-lists of the applicable
methods and decides what to do.  Therefore, I decided check-initargs
must be a metaclass method.  The alternative would have been to have
a check-initarg generic function that checks one argument at a time,
which seemed unduly complex.

Less clear is defaulting, but what decided me there was that at the
meeting there was a move to combine default-initargs and check-initargs
into a single operation, in which case they would have to be generic on
the same thing.  I don't really see much usefulness in users defining
their own default-initargs methods, when they are not working at the
metaclass level, so to keep things simple I made that generic on the
class.

It's true that in this formulation you can't do certain customized
defaulting and checking operations except by programming at the
metaclass level.  However, making those two functions generic on the
instance still wouldn't make those operations simple and easy to explain
(see mail discussion of the past few months), and I think at some point
we have to limit the ambitions of CLOS and say that it doesn't replace
all forms of programming.

That's why I proposed it the way I did.  This is not to say that no one
should propose that it work a different way, if they can refute the
arguments above.  For this purpose, default-initargs and check-initargs
should be discussed separately.