[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on latest draft documents
- To: Linda DeMichiel <LGD@SAIL.STANFORD.EDU>
- Subject: Re: Comments on latest draft documents
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 29 Jan 88 14:06 EST
- Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU
- In-reply-to: The message of 28 Jan 88 18:26 EST from Linda DeMichiel <LGD@SAIL.Stanford.EDU>
Date: 28 Jan 88 1526 PST
From: Linda DeMichiel <LGD@SAIL.Stanford.EDU>
In your message ``Comments on latest draft documents,'' you write:
2-17 class-name: The name of a class should not be restricted in type. The
method signature should specialize new-value with t, the arguments should
say new-value is typically a symbol, and the semicolon clause under
values should be deleted. While a class's proper name is a symbol
unless symbol-class is somehow extended, class-name should be allowed
to be any object. One proposed extension we discussed earlier has
class-name a list of classes.
Neither Dick nor I recall this having been decided. If this is really
what you want, I think you should bring this up for a vote on the list.
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.
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.
2-41 documentation method signatures: The parameter specializer name
for new-value should be t, not string. CLtL doesn't say anywhere what
values are allowed, but a reasonable inference is that NIL is allowed,
and "documentation information" might have been meant to include some
sort of structures as well. The allowable types here are a matter for
CL to define, not for CLOS to legislate.
t doesn't strike us as a reasonable generalization of string and nil.
It's the only one that CLOS has, since it doesn't allow OR. But
my point wasn't that the specializer should be (OR STRING NULL); my point
was that it's not up to CLOS to define the allowable types here, and as
far as the CLOS specification goes, the new-value parameter should not be
It seems to us that adding signatures for setf methods for (eql nil)
is a more sensible thing to do.
To me that's a much less sensible thing to do! The need to duplicate
the method shows that using the parameter specializer to do type-checking,
rather than specialization, was a mistake. At least that's how I see it.
I suppose none of this really matters, because it's only the method
signatures in the document, and we already agreed that those are going
to be discovered to be incorrect in the future.