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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
