Understanding globally frozen, locally mutable design
You learned in Chapter 3, Proper Variable Usage, about the benefits of frozen objects with an unfrozen internal cache. It is usually a good idea to freeze an object you do not plan to modify. This principle extends not just to regular objects, but to classes and modules as well.
In general, when you first load a library, you don't want it to be frozen, because then you cannot modify it. When Ruby starts up, it doesn't have any frozen classes; it allows the programmer to modify every class. This flexibility is very important during application setup. During application setup, before you start accepting user input, you generally want to have complete control to modify any part of the program.
However, in general, after application setup, this flexibility is unnecessary and can be actively harmful. In most cases, you don't want the classes or modules in your application to be modified at runtime. Modifying instances...
