Re: [Sbcl-devel] Bug report: dispatch on new-value of (setf slow-value-using-class)

[<lev...@gm...>]

Thanks for your reply, I think I see your points.

> rather than as places to hang application hooks onto (which is what I
> slightly presume your (setf slot-value-using-class) customization is
> intended for.  I think that if you want custom behaviour for a setter
> when given values of different classes, you probably ought to be
> specializing the setter function (e.g. an accessor) rather than
> slot-value-using-class directly.
The files I have sent are narrowed down from one of my projects where
the CLOS MOP is customized quite a bit that's why it looks weird.

There are of course some of other ways to do it (although I believe
this one is not misusing the concepts) but the main reason I brought
up this issue is that I think
 - (setf svuc) should either dispatch on new-value
 - or should signal a compile time error condition if one has given
type information for the new-value parameter

I think the current behavior is misleading and error prone. Especially
if you think of defining several (setf svuc)-s with different
new-value types and the result is this: only the last one is used
independently of the actual runtime type of the parameter. I had a
nice debug session before being able to identify this, so I thought
it's worth saving others falling into the same trap.

> (Having said all that, your code (sa.lisp) falls foul of one of the
> restrictions in AMOP, which is that all methods on a custom metaclass
> (i.e. a subclass of the various standardized metaclasses, such as
> slot-definition or class) must be defined before an instance of those
> metaclasses is created.  In your case, you create instances of
> sa-effective-slot-definition (by instantiating a finalizeable
> sa-class, topic, with a slot) before defining the (setf
> slot-value-using-class) methods specialized on it.  Unfortunately,
Ok, that can be fixed easily by moving the definition down before
test-it. The results are the same.

Cheers,
levy