From: <lev...@gm...> - 2006-05-03 20:41:43
|
Hi, Is it allowed at all? I did not find anything saying the opposite in the MOP spec. Ok, I'm not sure that this is a bug, but the behavior is quite strange I th= ink. If I define a custom (setf whatever) method with two different signatures for the new-value parameter (its type I mean), then everything is right. But if I do the same thing with (setf slot-value-using-class) then I get strange behavior. Please take a look at the attached files. Even though the SLIME inspector lists both method signatures it seems that the latter (in the file) overwrites the other one in some method cache or so. Ok, these are just my guesses without actually looking at the SBCL source. I'm using SBCL 0.9.11 with x86-64 backend on ubuntu linux. I have added the patch for the method cache bug which was reported by me earlier. I don't know if they are related. Cheers, levy -- There's no perfectoin |
From: Levente <lev...@gm...> - 2006-05-05 15:36:49
|
Me again, I tested it with a clean 0.9.11 and the bug exists there too. I'm planning to give it a try on 0.9.12 but I don't think there's anything changed related to this issue. As a side note: if I swap the two (setf s-v-u-c) methods then I get different bad behavior. Cheers, levy |
From: Christophe R. <cs...@ca...> - 2006-05-08 17:06:44
|
"Levente M=E9sz=E1ros" <lev...@gm...> writes: > Is it allowed at all? I did not find anything saying the opposite in > the MOP spec. > > Ok, I'm not sure that this is a bug, but the behavior is quite > strange I think. I don't know if I'm being terribly conservative here, but I think the original MOP authors would probably not want to allow dispatch on new-value in (setf slot-value-using-class). The basic reason for my feeling is an argument from symmetry. The four slot-valueish functions are meant to be implemented or extended in synchronization, and bad things happen if they're not; so if you extend (setf slot-value-using-class) for your custom slot-definition, but not slot-value-using-class, various other bits of CLOS will stop working. My view of those four functions is that they are the lowest level above structures, and describe how to implement accessing instances, 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. (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, this is not the only issue in the case under consideration; PCL's GET-ACCESSOR-METHOD-FUNCTION simply does not allow for specialization on new-value. I could probably fix it to, or else disable it when there are specializations on new-value, but I'm really not sure I want to...) Cheers, Christophe |
From: <lev...@gm...> - 2006-05-09 07:37:18
|
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 |
From: Christophe R. <cs...@ca...> - 2006-05-28 11:05:27
|
"Levente M=C3=A9sz=C3=A1ros" <lev...@gm...> writes: > 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 Compile-time? No, because that's not when method definitions happen. However, there is now (as of sbcl-0.9.13.4) a run-time error if the user attempts to add a method specializing on the new-value argument to (setf slot-value-using-class). I continue to believe that (setf slot-value-using-class) is not the right place to implement differences of behaviour for writers based on the class of the argument: think about it from the point of view of the protocol described in AMOP -- it does not make sense to me for the implementation of the slot setter to depend on the class of the value being set. (By all means come up with a concrete example, though :-) Cheers, Christophe |
From: <lev...@gm...> - 2006-05-29 07:34:36
|
> Compile-time? No, because that's not when method definitions happen. > However, there is now (as of sbcl-0.9.13.4) a run-time error if the > user attempts to add a method specializing on the new-value argument > to (setf slot-value-using-class). I guess this patch would have saved some time for me, thanks! > I continue to believe that (setf slot-value-using-class) is not the > right place to implement differences of behaviour for writers based on > the class of the argument: think about it from the point of view of > the protocol described in AMOP -- it does not make sense to me for the > implementation of the slot setter to depend on the class of the value > being set. (By all means come up with a concrete example, though :-) I can't give you a simple example and since one can always dispatch on the value's type in the method body, I think it's not that important. Still conceptually I don't see anything bad about having dispatch for that parameter just like in normal (setf xxx) generic methods. But clearly the problem I had was not being able to find out that this is not possible, so thanks for the patch! Cheers, levy |