Hi guys
is it me or we are missing some cool and simple methods like hasInstanceVariableNamed: hasClassVariableNamed: ? Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 26 August 2010 14:47, Stéphane Ducasse <[hidden email]> wrote:
> Hi guys > > is it me or we are missing some cool and simple methods > like > hasInstanceVariableNamed: > hasClassVariableNamed: > ? > i remember writing a code like: class allInstVarNames includes: somevar, multiple times, but i can't tell that i miss the above methods too much. I'd vote to add them, only if we , in exchange, find the other two(or more) methods to remove. A class protocol is heavily bloated, and adding even more on top of that, even if its userful, could be lost in a jungle of many others. > Stef > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
I tend to agree but not quite :)
Size is not the only criteria. Consistency is another really important one. And also tested code because there are plenty of methods that are not that difficult to rewrite all the time in client code but you want to use them because another guys spent time to write them and test them. And yes I started to read Class and Behavior and I want to clean that. As soon as Opal gets into pharo we will clean, clean, clean. Stef >> > i remember writing a code like: > class allInstVarNames includes: somevar, > multiple times, > but i can't tell that i miss the above methods too much. > I'd vote to add them, only if we , in exchange, find the other two(or > more) methods to remove. > A class protocol is heavily bloated, and adding even more on top of that, > even if its userful, could be lost in a jungle of many others. > >> Stef >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 |
what about
ClassDescription>>chooseInstVarThenDo: aBlock ClassDescription>>chooseInstVarAlphabeticallyThenDo: aBlock ClassDescription>>chooseClassVarName should I really comment.... I will fix them. On Aug 26, 2010, at 4:08 PM, Stéphane Ducasse wrote: > I tend to agree but not quite :) > > Size is not the only criteria. > Consistency is another really important one. > And also tested code because there are plenty of methods that are not that difficult to rewrite all the time > in client code but you want to use them because another guys spent time to write them and test them. > And yes I started to read Class and Behavior and I want to clean that. > As soon as Opal gets into pharo we will clean, clean, clean. > > Stef > > >>> >> i remember writing a code like: >> class allInstVarNames includes: somevar, >> multiple times, >> but i can't tell that i miss the above methods too much. >> I'd vote to add them, only if we , in exchange, find the other two(or >> more) methods to remove. >> A class protocol is heavily bloated, and adding even more on top of that, >> even if its userful, could be lost in a jungle of many others. >> >>> Stef >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 Igor Stasenko
for example
we have addClassVarName: classVarNamed: classVarNamed:put: removeClassVarName: I will rename addClassVarName: removeClassVarName: to be addClassVarNamed: removeClassVarNamed: consistency.... Stef _______________________________________________ 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 Aug 27, 2010, at 10:31 AM, Stéphane Ducasse wrote: > what about > > ClassDescription>>chooseInstVarThenDo: aBlock > > ClassDescription>>chooseInstVarAlphabeticallyThenDo: aBlock > > > ClassDescription>>chooseClassVarName > > should I really comment.... I will fix them. > This should not be in ClassDescription... the only client is SystemNavigation. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ 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
*Cough* deprecate *cough* ;)
Cheers, Henry On Aug 27, 2010, at 10:51 44AM, Stéphane Ducasse wrote: > for example > we have > addClassVarName: > classVarNamed: > classVarNamed:put: > removeClassVarName: > > I will rename > addClassVarName: > removeClassVarName: > > to be > addClassVarNamed: > removeClassVarNamed: > > consistency.... > > 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 |
> *Cough* deprecate *cough* ;)
what you got a flu :) Of course this is done and I would like to have a refactoring called renameDeprecate :) Lukas? :) Stef > > Cheers, > Henry > > On Aug 27, 2010, at 10:51 44AM, Stéphane Ducasse wrote: > >> for example >> we have >> addClassVarName: >> classVarNamed: >> classVarNamed:put: >> removeClassVarName: >> >> I will rename >> addClassVarName: >> removeClassVarName: >> >> to be >> addClassVarNamed: >> removeClassVarNamed: >> >> consistency.... >> >> 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 |
Free forum by Nabble | Edit this page |