[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on latest draft documents
- To: Moon@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Re: Comments on latest draft documents
- From: Danny Bobrow <Bobrow.pa@Xerox.COM>
- Date: 29 Jan 88 19:01 PST
- Cc: LGD@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Fri, 29 Jan 88 14:06 EST
- Sender: Bobrow.pa@Xerox.COM
I don't think anything was decided. My point is that it's
silly, in my opinion, to use parameter specializers on new-value
arguments to setf methods as a way of doing type-checking (rather
than specialization), and more importantly that I don't think the
CLOS specification should imply that if you need to store a
different type of value, you have to define your own method. I
suppose this comes down to the issue of what is the contract of the
method and what is the contract of the generic function, again.
Since we agreed not to try to solve that in chapter 2 this time
around, I would be happier if the method signatures didn't
specialize the new-value arguments.
I agree with this point. I think that in general it is a bad way of doing
business to specialize arguments in CLOS just for type checking purposes. It
implies that there might be other specializations, not that some of the
arguments determine the type for the rest of the arguments.
If anyone wants to argue for or against the class-name function
being restricted by the CLOS specification to return only symbols,
this is the place to speak up about it.
I would strongly prefer not to put this restriction on class-name at this time.