#initialize to superclass [was Re: [squeak-dev] The Trunk: Tests-mt.329.mcz]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
cbc
Reply | Threaded
Open this post in threaded view
|

#initialize to superclass [was Re: [squeak-dev] The Trunk: Tests-mt.329.mcz]

cbc
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.!







Reply | Threaded
Open this post in threaded view
|

Re: #initialize to superclass [was Re: [squeak-dev] The Trunk: Tests-mt.329.mcz]

marcel.taeumel
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
Reply | Threaded
Open this post in threaded view
|

Re: #initialize to superclass [was Re: [squeak-dev] The Trunk: Tests-mt.329.mcz]

Levente Uzonyi-2
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.!
>
>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: #initialize to superclass [was Re: [squeak-dev] The Trunk: Tests-mt.329.mcz]

Karl Ramberg
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.

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



--
View this message in context: http://forum.world.st/initialize-to-superclass-was-Re-squeak-dev-The-Trunk-Tests-mt-329-mcz-tp4846439p4846516.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.