Joachim -
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
new
^ 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.