Hi Levente,
On Thu, Aug 27, 2015 at 5:14 AM, Levente Uzonyi <[hidden email]> wrote: Unless you have a very good reason to send #initialize to the superclass, you shouldn't do it. So, I have two questions: 1 - why should we not do this? 2 - if we shouldn't do it, then why does the system ALWAYS bug us about not overriding #initialize when adding that method to the class side? I am in the habit of adding it - because the message pops up, and I suppose the system has a good reason for us to not override it. Maybe just a bad habit on my part. thanks, cbc Levente |
Iff the class-side #initialize changes, it will be re-executed.
The Editor class hierarchy overrides #initialize w/o sending super but helper methods (e.g. #initializeCmdKeyShortcuts), which do send super. I wonder, why. :) Best, Marcel |
In reply to this post by cbc
Hi Chris,
Class-side #initilize is mostly used to evaluate some code when the class is loaded into the image. The reason for this is that the method is not evaluated on class creation, only on class loading, and only the implementor will receive message, its subclasses will not. Most implementations assume that the method will never be sent more than once. A good example for the subclass handling is TestCase. If you were to create a subclass of it and implement #initialize on the class-side with a super send, then you'd find yourself having your subclass registered for all method changes. If this happen too many times, then your image will slow down for seemingly no reason. To make it harder to find out what the problem is, you'll only experience it when you load your code into another image. Another problem could be the propagation from class-side to the Behavior instance, but that's prevented by Object class >> #initilize, which intentionally omits the super send. If that method weren't there, then your class would get reinitialized by Behavior >> #initialize. The warning only says that the method has a special role in the system. It doesn't advice you to add a super send. Levente On Thu, 27 Aug 2015, Chris Cunningham wrote: > Hi Levente, > > On Thu, Aug 27, 2015 at 5:14 AM, Levente Uzonyi <[hidden email]> wrote: > Unless you have a very good reason to send #initialize to the superclass, you shouldn't do it. > > So, I have two questions: > 1 - why should we not do this? > 2 - if we shouldn't do it, then why does the system ALWAYS bug us about not overriding #initialize when adding that method to the class side? > > I am in the habit of adding it - because the message pops up, and I suppose the system has a good reason for us to not override it. Maybe just a bad habit on my part. > > thanks, > cbc > > Levente > > On Thu, 27 Aug 2015, [hidden email] wrote: > > Marcel Taeumel uploaded a new version of Tests to project The Trunk: > http://source.squeak.org/trunk/Tests-mt.329.mcz > > ==================== Summary ==================== > > Name: Tests-mt.329 > Author: mt > Time: 27 August 2015, 11:12:04.169 am > UUID: 2665a1ed-6312-1845-8181-d83c588cd161 > Ancestors: Tests-mt.328 > > Fixes initialization problem with test preferences. > > =============== Diff against Tests-mt.328 =============== > > Item was added: > + ----- Method: PreferencesTestPreferences class>>initialize (in category 'class initialization') ----- > + initialize > + > + super initialize. > + self initializeDictionaryOfPreferences.! > > > > > > > |
In reply to this post by marcel.taeumel
Hi, With latest updates there is a issue with Preference>>categoryList which now returns false instead of a list. Karl On Fri, Aug 28, 2015 at 9:50 AM, marcel.taeumel <[hidden email]> wrote: Iff the class-side #initialize changes, it will be re-executed. |
Free forum by Nabble | Edit this page |