[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
type slot option
re: One of the comments we received attacked several problems with the :type
slot option. The complaint, which came from Dan Pierson, sees to be
that because the :type option is not enforced by automatically defined
accessors or slot-value, you can't count on it to protect a slot from
having the wrong type of value stored in it. It seems he is thinking of
the type option as a `semantic' feature, rather than an optional
compiler declaration.
Some of the comments you mailed out seem to be addressing this issue as
if it were yet another facet of the stock-hardware-inspired "declaration"
war. But in fact the criticism directed against it is precisely that it
is viewed only as an ignorable "declaration". Pierson's desires would be
fully satisfied, I think, if there were some mode in which the :type options
were enforced as a semantic feature. I've seen such comments on the
common-lisp mailing list too -- that there ought to be at least one mode
of interaction with the system such that defstruct slot access is always
"type-checked" (translate that to slot access for CLOS). Again, I emphasize
that this is not a LispM-versus-stock-hardware issue, since the type-checking
involved is not the kind that is being done by the special purpose hardware.
Interlisp had a feature like this that was a run-time checked declaration.
I can't remember right now what it was called.
Perhaps a reasonable way out of the situation is to "defer" it to CL's
treatment of the :type option in defstruct. If ever there is mandated
such a "mode" as I referred to for defstruct, then CLOS could follow the
same protocol.
-- JonL --