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?