Re: [Sbcl-devel] TYPE-CHECK-FUNCTION in DEFCLASS expansion

[Christophe R. <cs...@ca...>]

Nathan Froyd <fr...@cs...> writes:

> On Sun, Dec 24, 2006 at 04:50:46AM +0300, Ivan Shvedunov wrote:
>>   When porting some my MOPish code from CMUCL I've noticed that SBCL's
>> slot type checking became somewhat hard to defeat. What I need is to be able
>> to specify some stuff in :type of object slots for classes with my metaclass
>> for my own purposes such as parsing user input and then hide these types
>> from underlying CLOS machinery so that e.g. I can store NIL values in slots
>> that have :type some-my-object.
>
> Why do you need to lie to the compiler about the type of value stored in
> these slots?  It sounds as though all you need to do is say ':TYPE
> (OR NIL MY-TYPE)' and everything will be OK.

I find this issue slightly more subtle, actually.  Although CLHS is
clear about what :type means in a DEFCLASS form, and formally Nathan
is right that this rewriting of slot types is a bad idea, I think it's
a lot less clear-cut when you consider the various protocols that the
MOP involves.  Until the type checking code was added, it was possible
to define your own slot definition types, for which the :TYPE initarg
would have a different meaning -- and I think that, since you could
only get this different meaning by extending various system classes in
an extra-ANSI-standard way, that this was basically reasonable
behaviour.

Of course, I think the current behaviour (to treat :TYPE always with
its ANSI-specified meaning) is probably better in the long run, but I
am willing to believe that it will cause some short-term pain to MOP
users -- and it might make it impossible to maintain an absolutely
compatible interface with CommonSQL, say.  So we need to be clear on
the implications, I think, and consider whether there's a more MOPpish
way of achieving the same thing.

Cheers,

Christophe