On 27 Dec 2006, at 15:20, Christophe Rhodes wrote:
> Pascal Costanza <pc@...> writes:
>> On 27 Dec 2006, at 14:34, Christophe Rhodes wrote:
>>> 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
>>> way of achieving the same thing.
>> I think the MOPpish way to modify the type of a slot is to create
>> your own effective slot definition class and do what's necessary in
>> in :around method for initialize-instance on that class.
> Well, yes, but that's not actually the point.
> The point is that at the moment, SBCL enforces the ANSI restriction
> that the argument to a :TYPE slot option defines the acceptable types
> of the slot initform by inserting a type check, even if the effective
> slot definition will eventually be of a different class: that is, the
> type check is inserted by SBCL at macroexpansion time, before any
> objects have been created. As I say, I believe that SBCL is justified
> in doing so, independently of the MOP, because ANSI defines this
> meaning for the :TYPE slot option; however, the question is whether
> there is a different way for SBCL to perform this checking, in a way
> that is more overrideable by users of the MOP.
When checking the macroexpansion of a defclass form, what I see is
that a typecheck function is created from the slot specification. So
what is happening seems to be similar to the initform / initfunction
pair that is already part of the CLOS MOP.
You could avoid problems here by delaying the check until class
finalization and then checking the initform against the type of the
respective effective slot definition. Then the MOP programmer has a
single point of modifying slot types, and that is in the initialize-
instance methods for effective slot definitions. You wouldn't need
the extra type-check-function anymore, AFAICT.
Of course, one could also change the type-check function in
initialize-instance methods for the metaclass, but that's a little
less convenient because you would have to modify the canonicalized
slot specification instead of a real slot definition metaobject.
Note also that creating a pair of type / type-check-function indeed
creates similar issues like that for initform / initfunction pairs.
(For example, is it an error to specify only one but not the other
when programmatically creating classes?)
For MOP programmers, there is also already a problem that the
initform / initfunction pairs have to be specially treated internally
without having a way to perform similar modifications oneself.
LispWorks has a nice interface for parsing slot and class options.
lwref-12.htm and http://www.lispworks.com/documentation/lw50/LWRM/
Pascal Costanza, mailto:pc@..., http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium