Madhu wrote: > * Raymond Toy <[EMAIL PROTECTED]> : > Wrote on Wed, 26 Nov 2008 17:08:56 -0500: > > | Didier Verna wrote: > > |> Section "2.23.2 Slot Type Checking" continues to puzzle me, > |> especially the fact that you have to be within *methods* for the > |> :type slot option to be taken in consideration when writing something > > Which section is this? I couldnt grep for this in the spec or mopspec. > Yeah, this confused me too. Sec 2.23.2 is referring to the CMUCL User's Manual. > > |> to a slot. For instance, with: > |> > |> (defclass foo () > |> ((a :type fixnum))) > |> > |> (defvar *object* (make-instance 'foo)) > |> (setf (slot-value *object* 'a) 3.5) ;; this works like a charm > |> > |> > |> but: > |> > |> (defmethod setslot ((foo foo) val) > |> (setf (slot-value foo 'a) val)) > |> > |> (setslot *object* 3.5) ;; triggers a type error > |> > |> > |> Can somebody provide a rationale for this ?? > |> > |> > |> > | Most likely because no got around to doing it. Plus the most > | interesting/most common case is probably in a method. > | > | I'll see what I can do, but I know very little about the pcl > | implementation. > > It may also have been a tradeoff, [since it is not being done in the > compiler] and you want to have at least one path available to the > programmer to set a slot value that avoids overhead of a type check. I've implemented this already. It basically does a check-type for (setf slot-value) for standard objects. This doesn't change what happens when slot-value is used in a method.
I don't follow why there should be a path that avoids the type check overhead. I'm not sure, but it wouldn't surprise me some compiled methods behave strangely if the slot doesn't have the specified type. (Untested, though.) Ray
