About super initialize

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

About super initialize

Stéphane Ducasse
Hi

in http://code.google.com/p/pharo/issues/detail?id=135 may be stupidly  
I was thinking that it would be nice to
check all the initialize methods that are not doing a super call, and  
fix them.
Alain did this crazy and boring tasks and I was reviewing his code.
Now I was wondering if it makes sense to add super initialize to the  
direct subclasses of Object.
I have the impression that it is good for uniformity but we are  
calling an empty so we could
do the following only fix the caller that are not subclasses of Object.

What is your point of view,

stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Nicolas Cellier
If ever you want to change these messages, please run some benchmark.

2009/6/8 Stéphane Ducasse <[hidden email]>:

> Hi
>
> in http://code.google.com/p/pharo/issues/detail?id=135 may be stupidly
> I was thinking that it would be nice to
> check all the initialize methods that are not doing a super call, and
> fix them.
> Alain did this crazy and boring tasks and I was reviewing his code.
> Now I was wondering if it makes sense to add super initialize to the
> direct subclasses of Object.
> I have the impression that it is good for uniformity but we are
> calling an empty so we could
> do the following only fix the caller that are not subclasses of Object.
>
> What is your point of view,
>
> stef
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Mariano Martinez Peck
In reply to this post by Stéphane Ducasse


On Mon, Jun 8, 2009 at 3:13 PM, Stéphane Ducasse <[hidden email]> wrote:
Hi

in http://code.google.com/p/pharo/issues/detail?id=135 may be stupidly
I was thinking that it would be nice to
check all the initialize methods that are not doing a super call, and
fix them.
Alain did this crazy and boring tasks and I was reviewing his code.
Now I was wondering if it makes sense to add super initialize to the
direct subclasses of Object.

I don'' understand why. If ProtoObject>>initialize  is implemented like this:

initialize
    "Subclasses should redefine this method to perform initializations on instance creation"

why should direct subclasses of Object call super initialize? uniformity as you said ?
 

I have the impression that it is good for uniformity but we are
calling an empty so we could
do the following only fix the caller that are not subclasses of Object.

What is your point of view,

stef


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Damien Cassou
In reply to this post by Stéphane Ducasse
On Mon, Jun 8, 2009 at 6:13 PM, Stéphane
Ducasse<[hidden email]> wrote:
> I was thinking that it would be nice to
> check all the initialize methods that are not doing a super call, and
> fix them.

Are we sure that no #initialize method avoid calling super initialize
on purpose?

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Christian Haider
In reply to this post by Stéphane Ducasse
I would get rid of these #initialize methods and use lazy initialization instead.
Simple redefinitions in subclasses, no worries.

Cheers,
        Christian

> -----Ursprüngliche Nachricht-----
> Von: [hidden email]
> [mailto:[hidden email]] Im
> Auftrag von Stéphane Ducasse
> Gesendet: Montag, 8. Juni 2009 18:15
> An: Pharo Development
> Betreff: [Pharo-project] About super initialize
>
> Hi
>
> in http://code.google.com/p/pharo/issues/detail?id=135 may be
> stupidly  
> I was thinking that it would be nice to
> check all the initialize methods that are not doing a super
> call, and  
> fix them.
> Alain did this crazy and boring tasks and I was reviewing his code.
> Now I was wondering if it makes sense to add super initialize to the  
> direct subclasses of Object.
> I have the impression that it is good for uniformity but we are  
> calling an empty so we could
> do the following only fix the caller that are not subclasses
> of Object.
>
> What is your point of view,
>
> stef
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Alain Plantec-4
In reply to this post by Stéphane Ducasse
Stéphane Ducasse a écrit :
> Hi
>
> in http://code.google.com/p/pharo/issues/detail?id=135 may be stupidly  
> I was thinking that it would be nice to
> check all the initialize methods that are not doing a super call, and  
> fix them.
> Alain did this crazy
yes!
> and boring
yes! :-D
> tasks and I was reviewing his code.
> Now I was wondering if it makes sense to add super initialize to the  
> direct subclasses of Object.
> I have the impression that it is good for uniformity but we are  
> calling an empty so we could
> do the following only fix the caller that are not subclasses of Object.
>
> What is your point of view,
>  
mainly, good for uniformity
alain

> stef
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>  


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Nicolas Cellier
In reply to this post by Christian Haider
2009/6/8 Christian Haider <[hidden email]>:
> I would get rid of these #initialize methods and use lazy initialization instead.
> Simple redefinitions in subclasses, no worries.
>
> Cheers,
>        Christian
>

Using this pattern here and there is at an affordable cost.
But generalizing it, you take the risk to multiply cost of every
access to an inst var by a huge amount.
That would deserve some bench too.

Nicolas


PS: I'd like to have time to spend thinking about a system that would
dynamically change methodDictionary per instance based on previous
execution results for such typical cases.

>> -----Ursprüngliche Nachricht-----
>> Von: [hidden email]
>> [mailto:[hidden email]] Im
>> Auftrag von Stéphane Ducasse
>> Gesendet: Montag, 8. Juni 2009 18:15
>> An: Pharo Development
>> Betreff: [Pharo-project] About super initialize
>>
>> Hi
>>
>> in http://code.google.com/p/pharo/issues/detail?id=135 may be
>> stupidly
>> I was thinking that it would be nice to
>> check all the initialize methods that are not doing a super
>> call, and
>> fix them.
>> Alain did this crazy and boring tasks and I was reviewing his code.
>> Now I was wondering if it makes sense to add super initialize to the
>> direct subclasses of Object.
>> I have the impression that it is good for uniformity but we are
>> calling an empty so we could
>> do the following only fix the caller that are not subclasses
>> of Object.
>>
>> What is your point of view,
>>
>> stef
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Alain Plantec-4
In reply to this post by Damien Cassou
Damien Cassou a écrit :

> On Mon, Jun 8, 2009 at 6:13 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>  
>> I was thinking that it would be nice to
>> check all the initialize methods that are not doing a super call, and
>> fix them.
>>    
>
> Are we sure that no #initialize method avoid calling super initialize
> on purpose?
>  
Hi Damien,
my opinion is that such a situation reveals a design problem which
should be fixed.
but it is only my opinion.
Cheers
alain


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Stéphane Ducasse
In reply to this post by Damien Cassou

On Jun 8, 2009, at 6:36 PM, Damien Cassou wrote:

> On Mon, Jun 8, 2009 at 6:13 PM, Stéphane
> Ducasse<[hidden email]> wrote:
>> I was thinking that it would be nice to
>> check all the initialize methods that are not doing a super call, and
>> fix them.
>
> Are we sure that no #initialize method avoid calling super initialize
> on purpose?

most of them predate the new/initialize patterns.
on all the changes alain did I found so far only one mistake :)

stef

>
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Stéphane Ducasse
In reply to this post by Nicolas Cellier

> If ever you want to change these messages, please run some benchmark

ok but when you have a class 4 level deep that has subclasses and an  
initialize and ...
it means that when we will change its superclass Model we will get  
some bugs.

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Stéphane Ducasse
In reply to this post by Alain Plantec-4
Mine too.
I have some serious doubt about the TTCompositeGlyph subclass of  
TGlyph when the initialize is not called.

On Jun 8, 2009, at 10:08 PM, Alain Plantec wrote:

> Damien Cassou a écrit :
>> On Mon, Jun 8, 2009 at 6:13 PM, Stéphane
>> Ducasse<[hidden email]> wrote:
>>
>>> I was thinking that it would be nice to
>>> check all the initialize methods that are not doing a super call,  
>>> and
>>> fix them.
>>>
>>
>> Are we sure that no #initialize method avoid calling super initialize
>> on purpose?
>>
> Hi Damien,
> my opinion is that such a situation reveals a design problem which
> should be fixed.
> but it is only my opinion.
> Cheers
> alain
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Mariano Martinez Peck
In reply to this post by Stéphane Ducasse



Still I have the impression that for direct subclasses of Object super
initialize is unnecessary

+1
 

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Lukas Renggli
In reply to this post by Stéphane Ducasse
> 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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Alain Plantec-4
Lukas Renggli a écrit :

>> 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.
>
>  
I could not say  it better, this is exactly what I think.

alain


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About super initialize

Stéphane Ducasse
Ok you convinced me.
Alain I will go over your fixes again because I stopped in the middle :)

Stef
On Jun 9, 2009, at 1:01 PM, Alain Plantec wrote:

> Lukas Renggli a écrit :
>>> 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.
>>
>>
> I could not say  it better, this is exactly what I think.
>
> alain
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project