I do not think that we will hev speed impact but yes we should run that. Still I have the impression that for direct subclasses of Object super initialize is unnecessary
If you follow this pattern refactoring code (moving classes in hierarchies) can easily introduce bugs. Furthermore it is already complicated enough for beginners to know when to call super initialize and when not (the class side). So I would strive for the simplest and most uniform solution --- always call super initialize. In Seaside we always call super initialize, even if the initialize method is empty. This is more uniform and makes refactoring easier. The only exception for this rule is the single direct subclass of Object we have, WAObject. This class does not call super initialize solely for portability reasons, no other Smalltalk implements #initialize on Object. Of course we have various Lint rules that check the initialize patterns in the Seaside code. I guess they could be (adapted and) run on Pharo code too. If you want me to run them, let me know and I can post a list of the offending methods. Lukas -- Lukas Renggli http://www.lukas-renggli.ch