About super initialize
Locked
 
|
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 |
|
|
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 |
Re: About super initialize
|
|
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 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 ?
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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 |
|
|
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? > 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 |
|
|
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 |
|
|
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 |
|
|
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 |
Re: About super initialize
|
|
In reply to this post by Stéphane Ducasse
+1
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 |
|
|
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. > > alain _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |