[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 --