> Can I ask why you invoke #'CL:CHANGE-CLASS on an object instead of simply creating a new instance of the second class with adequate initialization?
Because you’d have to go find all the pointers to the old instance. Maybe you don’t want to do that. Or maybe you don’t care, but that’s ok because what CLOS gives you is possibilities.
Yes, preserving instance identity is at the core of the question. It could even be the only question here. Is there any other?
But what looks like an occasional convenience comes at a cost.
Class redefinition is cheap, in the sense that until you touch each instance (i.e. passing it to a method) no work is done on it. I suspect — but can’t remember the details — that cl:change-class recalculated slots on the spot.
- nick
BTW, I just remembered that PCL (that venerable demonstration implementation of CLOS) contains all the machinery needed to implement that identity preservation feature as application level code expressed in CLTL1 compatible code.
So this shows that the whole thing could be implemented as a library/package all from the beginning.
It is a proof of concept of some kind I would say.