From: Bruno H. <br...@cl...> - 2004-05-03 21:02:40
|
Christophe Rhodes wrote: > > The problem of consecutive class redefinitions resulting in a single call > > to update-i-f-r-c remains. > > It's a problem, but I'm not certain it's a bug. Well, I gave an example showing that this behaviour has the consequence that the presence or absence of a SLOT-VALUE access at a particular moment has an influence on the values of unrelated slots later. http://www.caddr.com/macho/archives/sbcl-devel/2004-4/3306.html That's insane behaviour, if just looking at a slot makes a program run differently. > I can't see _any_ way to do the > right thing, given that you can't have two methods for the same class > (one for 1->2; one for 2->3)... The user can write a single method that handles the transitions 1->2 and 2->3 simultaneously, by looking at the added-slots, discarded-slots and plist arguments that are passed. When you call U-I-F-R-C just once, his method has also to take into account the transition 1->3, which is more work for the user. Bruno |
From: Nikodemus S. <tsi...@cc...> - 2004-05-03 21:40:24
|
On Mon, 3 May 2004, Bruno Haible wrote: > The user can write a single method that handles the transitions 1->2 and 2->3 > simultaneously, by looking at the added-slots, discarded-slots and plist Theoretically, but since this requires that all the old transitions need to be handled onto the umpteenth redefinition it doesn't really scale. I suspect that saving the current update method in the wrapper when the wrapper is obsoleted, and then going thru all the saved methods in order when updating the instance is the way to go. Not that I'm surprised if it turns out "rather complex". ;) Cheers, -- Nikodemus |
From: Bruno H. <br...@cl...> - 2004-05-04 09:58:51
|
Nikodemus Siivola wrote: > Theoretically, but since this requires that all the old transitions need > to be handled onto the umpteenth redefinition it doesn't really scale. Asking the user to implement the transitions 1->2, 2->3, ..., N-1->N in his u-i-f-r-c method scales better than asking him to implement the N(N-1)/2 transitions 1->2, 1->3, ..., 1->N, 2->3, ..., 2->N, ......., N-1->N in his method. Or, if you think that implementing even the N-1 transitions 1->2, 2->3, ..., N-1->N in a single method is too complex, the implementation should provide a generic function MAKE-INSTANCES-OBSOLETE-AND-UPDATE-NOW. The reason why this function is not in the standard is probably because it requires a scan of the entire heap. > I suspect that saving the current update method in the wrapper when the > wrapper is obsoleted, and then going thru all the saved methods in order > when updating the instance is the way to go. Saving information in the obsoleted wrapper is of course the way to do it, but I wonder whether it's allowed to save a GF's method in order to call it later, when it has been replaced by another method...? And how CALL-NEXT-METHOD will behave in such a case? Bruno |
From: Nikodemus S. <tsi...@cc...> - 2004-05-04 10:13:29
|
On Tue, 4 May 2004, Bruno Haible wrote: > Or, if you think that implementing even the N-1 transitions 1->2, 2->3, > ..., N-1->N in a single method is too complex, the implementation should Yes, this is what I ment. > Saving information in the obsoleted wrapper is of course the way to do it, > but I wonder whether it's allowed to save a GF's method in order to call I certainly haven't thought the details thru yet, but obviously call-next-method needs to be taken into account. Cheers, -- Nikodemus |