Lambda the Ultimate

This doesn't seem like as big of a problem as you are making it. The Memento design pattern calls for the originator to be an object which creates its own memento objects as well as taking them back from its caretaker to handle its own rollbacks. An object that handles its own rollbacks may internally keep instances of classes that may need to change, but a memento object would have all the information needed to recreate an object from scratch, and since the originator provides all the means to externally access this object that needs to be of a different class anyway, there is no real hassle doing any necessary rewiring internally. This seems a pretty elegant solution, considering the apparent complexity of the task.

I realize I am sidestepping your question. I apologize. However, languages that support so-called "duck typing," such as Ruby, could fit your description easily, though I am sure it's not the only way.

I'm familiar with Python which is fairly equivalent to Ruby and I don't see how it could solve this problem. I think it'd be _harder_, in that you can't rely on replacing the same area of memory.

Writing code for handling rollbacks is bug prone compared to just making a copy, I wouldn't really consider that a solution. The Memento pattern is going to require you to write a wrapper class that contains references to all of the different types you want it to be able to "become." Continuing the original example it would need to hold a 2D plot and a 3D plot reference. More boilerplate.

a = Dog()
b = Cat()
c = b
b = a

The type of c is Cat, not Dog. That's not a replacement. Now that I think about it, I think you could hack it with something like:

for member in dir(b): del member

# syntax probably slightly wrong
for member in dir(a): setattr(b, member, a.member)

The key distinction between replacement and assignment would be that with replacement, all references in the program to original now refer to the replacement. Assignment doesn't do that.

The only way to do what you want is to add another layer of indirection. One pointer isn't enough. In C++, either you need to use a handle (a pointer to a pointer) explicitly or implicitly (with a smart pointer class). In Python, you need to write a reference object that either explicitly or implicitly (using __getattr__ and __setattr__) redirects attribute access. Actually mutating an object into an arbitrarily different object is possible in some languages (including Python, for most objects), but it's ugly and certainly a case where the cure is worse than the disease.

You might think about immutable datatypes or object prototypes which will never be changed. Instead a mutation creates a new object that refers to the prototype recursively. Therefore all state changes are preserved. If you want to set global checkpoints you might store references to objects in a separate stack. If the user wants to time-travel back to a previous system state ( associated uniquely with pushing a reference on the stack ) you just have to delete all objects which are subsequent to this state.

you could just have the behavior of A change so that all it does is forward any messages sent to it on to A instead. IIRC, Objective-C had this as a system-provided method, something like [A delegateTo: B]. Now since Objective-C wasn't a pure message-passing language, this wouldn't make A completely equivalent to B: since == isnt' a method call, A==B would still be false. Otherwise, it would seem to be basically what you're looking for.

IIRC, Squeak has this feature, where it is called "become", although I'm having a hard time finding a link. Chicken Scheme has the same functionality under the name object-become!.

I think that Common Lisp's objects permit what you want. The relevant line in the specification is

Note that changing the class of an instance may cause slots to be added or deleted. Changing the class of an instance does not change its identity as defined by the eq function.

Here is an example. First define two classes.

CL-USER> (defclass 2d ()
           ((x :accessor x :initarg :x)
            (y :accessor y :initarg :y)))

CL-USER> (defclass 3d (2d)
           ((z :accessor z :initarg :z)))

Next define two overwrite methods. They use change-class to adjust the objects prior to copying the data. That way object identity is preserved.

CL-USER> (defmethod overwrite ((to 2d)(from 3d))
           (change-class to '3d 
                         :x (x from)
                         :y (y from)
                         :z (z from)))

CL-USER> (defmethod overwrite ((to 3d)(from 2d))
           (change-class to '2d
                         :x (x from)
                         :y (y from)))

CL-USER> (defparameter original (list (make-instance '2d :x 1 :y 2)
                                      (make-instance '3d :x 3 :y 4 :z 5)))

CL-USER> (defparameter new (list (make-instance '3d :x 6 :y 7 :z 8)
                                 (make-instance '2d :x 9 :y 10)))

CL-USER> (defmethod print-object ((o 2d) stream)
           (format stream "[~D,~D]" (x o)(y o)))

CL-USER> (defmethod print-object ((o 3d) stream)
           (format stream "(|~R:~R:~R|)" (x o)(y o)(z o)))

CL-USER> original
([1,2] (|three:four:five|))

CL-USER> new
((|six:seven:eight|) [9,10])

CL-USER> (defparameter elsewhere (vector (first new) (second new)))

CL-USER> elsewhere
#((|six:seven:eight|) [9,10])

CL-USER> (mapc (function overwrite) new original)
([1,2] (|three:four:five|))

CL-USER> elsewhere
#([1,2] (|three:four:five|))