[Pharo-project] hasInstanceVariableNamed: hasClassVariableNamed:
Hi guys is it me or we are missing some cool and simple methods like hasInstanceVariableNamed: hasClassVariableNamed: ? Stef
On 26 August 2010 14:47, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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.
for example we have addClassVarName: classVarNamed: classVarNamed:put: removeClassVarName: I will rename addClassVarName: removeClassVarName: to be addClassVarNamed: removeClassVarNamed: consistency.... Stef
*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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Henrik Johansen -
Igor Stasenko -
Marcus Denker -
Stéphane Ducasse