While implementing an empty Object>>initialize
method is relatively safe when done 'after the fact' (i.e., in V8.x of the product) since its only negative effect can be to hide the fact that your own initialize
method is missing, the same cannot be said for new
First, the question is where to put it. Since Behavior already impements new
as a primitive, Object class>>new
is the only alternative. If this had been done in V1.0 of VisualAge Smalltalk, there would not be an issue, but now the image is littered with new
methods implemented as:
- Code: Select all
^ super new initialize
What happens when we slip this method in at the root of the Object hierarchy 'after the fact'? Well, let's look at a class that already implements new
in the same way. That class now gets double initialized (at least) since the effect of its new
method changes from returning super new initialize
to returning super new initialize initialize
. Now maybe this does nothing but consume a few extra cycles, but since there is no guarantee that the result of executing an initialize
method multiple times is idempotent (I've been waiting for years to be able to use that word
), it also could lead to changes in behavior and hard-to-debug errors.
I have some (bad) experience with changing things in this area. Once, long ago, I blindly added an initialize
method to a class as a class extension. This caused the behavior of subclasses of the class I extended to change depending on whether or not the application containing my class extension was packaged into the runtime image. I now think very carefully before making changes to the base image -- and I still make an occasional mistake anyway.
John O'Keefe [|], Principal Smalltalk Architect, Instantiations Inc.