If e.g. an API wants to support monkey patching that's a decision that can be made. But thinking that any e.g. plugin or addin could could redefine extant class instances sounds like a nightmare, and a security issue just waiting to happen.
In longrunning/high-availability applications, this sort of thing is necessary in order to avoid restarting and losing uptime or state. E.G. per nasa:
> The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem
Any code modification is a potential security issue. There is nothing special about dynamic class redefinition in this regard.
I use it for development and deployment. I can deploy new code without having to take my application down. In fact, not only do all my existing instances get updated, but I also use an ORM [1] that automatically updates my database tables too.
I use Common Lisp in my day job, and I generally build software by livecoding, so I use this and other interactive programming support on a daily basis. Seems "legitimate" to me. I don’t want to have to stop my work-in-progress program running and lose all of the incremental state I’ve built just because I redefined a class or something.
I can agree that the most common uses are for development in progress, but I wouldn’t go so far as to say I wouldn’t use those facilities in a fully worked-out program. A sibling comment offers one reasonable example. I’ve done similar things before and probably will do them again.
Shinmera's Trial game engine, used in Kandria (which you can find on Steam), uses bits of the same machinery to implement the resourc system inside the game.
IIRC it has separate classes for "unloaded entity" and classes for various types of resources, and the protocol (think interface) for them includes the generic function that loads them into memory. The implementation of said function for unloaded objects uses CHANGE-CLASS method redefine the instance in place - meaning all direct memory pointers to the class are still valid and you don't need to use extra layer of indirection.
If e.g. an API wants to support monkey patching that's a decision that can be made. But thinking that any e.g. plugin or addin could could redefine extant class instances sounds like a nightmare, and a security issue just waiting to happen.