We’ll now describe, briefly, the standard generic function shared-initialize.  The way this function is interesting to the programmer is very much like that of initialize-instance, so the reader might want to review that earlier article.  In that article, I discussed how initialize-instance is called within make-instance, and by specializing an :after method on initialize-instance, it is possible to write additional code similar to what a C++ programmer would think of as the body of a constructor.  Where initialize-instance fills in the slots, like the initialization list in a constructor, the :after method on it allows the programmer to do other things than just fill in member slots.

Since that article appeared, though, we’ve talked about other ways that an object can be made.  We saw reinitialize-instance, and make-instances-obsolete, the latter as a prelude to update-instance-for-redefined-class, which we have not yet discussed.  These two cases, which do not correspond to any obvious C++ equivalent, do not call initialize-instance, so the programmer’s :after method won’t be called if they are used.

This is where shared-initialize enters the picture.  The shared-initialize generic function is called by initialize-instance, and also by reinitialize-instance, update-instance-for-redefined-class, and update-instance-for-different-class.  That means that by specializing an :after method on shared-initialize, just the way we did it earlier for initialize-instance, we can write code that will be executed whenever the new object is created by any of these routes.  Naturally, if the code should do different things for these different cases, you’ll want to specialize on the outer methods, but if they all have to run the same code, shared-initialize covers all the cases at once.