Re: [Pharo-project] What are the messages where we should always have a super send?
Hi, On 19/01/13 10:16, Stéphane Ducasse wrote: Hi jan do you have an example of such tagging? Look at RBTranslateLiteralsInMenusRule classtagsBasic, RBNilOrEmptyCollectionReplaceRule, RBMethodSourceContainsLinefeedRule, RBTempsReadBeforeWrittenRile RBLawOfDemeterRule RBContainsNamespaceIdentifiersRule at http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ Some comment on tagging http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?revision=1.9view=markup Could you please give me a pointer where newest Lint for Pharo lives? Cheers, Jan Right now we are also thinking that we want three kinds of rules - 1 whose result is either zero because there is no problem or zero because we flag the false positives - 2 more fuzzy one where we should have flase positive defined per package - 3 more statistical rules (long methods, large number of instance variables) We are checking how we can find decent threshold values not generating thousands of warnings and also if we want to embed false positives for them too. May be they are just good for trend analysis and when you want to spot ugly code but you do not care to have them under your nose systematically. For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds …. without having to recompile a method. This way people will be able to use their own conventions. Stef On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: Hi Stef, while massaging SmallLint rules, you should also have look at Smalltalk/X version of SmallLint [1] as we have ported Pharo version and improved some rules. I have also added a tagging system. That's useful for some rules are only good if you want to ensure portable code, some are simply broken and some stupid, etc. Having them properly classified would help us all. Tell me once you finish your ride, I'll merge changes back :-) Jan [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ to checkout issue: cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ On 18/01/13 17:06, Stéphane Ducasse wrote: Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef
Re: [Pharo-project] What are the messages where we should always have a super send?
Yes, #setUp and #tearDown Really. Ok I was not aware of it. Good idea. Stef For #initialize, having a super may not be that necessary if you working on the class side. Alexandre On Jan 18, 2013, at 12:06 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] What are the messages where we should always have a super send?
On Jan 22, 2013, at 7:19 AM, Jan Vrany wrote: Hi, On 19/01/13 10:16, Stéphane Ducasse wrote: Hi jan do you have an example of such tagging? Look at RBTranslateLiteralsInMenusRule classtagsBasic, RBNilOrEmptyCollectionReplaceRule, RBMethodSourceContainsLinefeedRule, RBTempsReadBeforeWrittenRile RBLawOfDemeterRule RBContainsNamespaceIdentifiersRule at http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ Some comment on tagging http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/RBLintRule.st?revision=1.9view=markup Ok It is a good idea. What is the license of the changes you did? And sorry but we do not want to have author in comment for the moment :) Could you please give me a pointer where newest Lint for Pharo lives? For now it lives in Pharo20. Once we migrate for real to smalltalkHub I want to have subprojects for RB, SmallLint. We tried for while to have none disruptive changes by putting changes as extensions of code critics but it does not work for cleaning the rules. Stef Cheers, Jan Right now we are also thinking that we want three kinds of rules - 1 whose result is either zero because there is no problem or zero because we flag the false positives - 2 more fuzzy one where we should have flase positive defined per package - 3 more statistical rules (long methods, large number of instance variables) We are checking how we can find decent threshold values not generating thousands of warnings and also if we want to embed false positives for them too. May be they are just good for trend analysis and when you want to spot ugly code but you do not care to have them under your nose systematically. For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds …. without having to recompile a method. This way people will be able to use their own conventions. Stef On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: Hi Stef, while massaging SmallLint rules, you should also have look at Smalltalk/X version of SmallLint [1] as we have ported Pharo version and improved some rules. I have also added a tagging system. That's useful for some rules are only good if you want to ensure portable code, some are simply broken and some stupid, etc. Having them properly classified would help us all. Tell me once you finish your ride, I'll merge changes back :-) Jan [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ to checkout issue: cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ On 18/01/13 17:06, Stéphane Ducasse wrote: Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef
Re: [Pharo-project] What are the messages where we should always have a super send?
Hi jan do you have an example of such tagging? Right now we are also thinking that we want three kinds of rules - 1 whose result is either zero because there is no problem or zero because we flag the false positives - 2 more fuzzy one where we should have flase positive defined per package - 3 more statistical rules (long methods, large number of instance variables) We are checking how we can find decent threshold values not generating thousands of warnings and also if we want to embed false positives for them too. May be they are just good for trend analysis and when you want to spot ugly code but you do not care to have them under your nose systematically. For the rules I'm also changing the implementation to make sure that we can customized the list of selectors, thresholds …. without having to recompile a method. This way people will be able to use their own conventions. Stef On Jan 18, 2013, at 6:24 PM, Jan Vrany wrote: Hi Stef, while massaging SmallLint rules, you should also have look at Smalltalk/X version of SmallLint [1] as we have ported Pharo version and improved some rules. I have also added a tagging system. That's useful for some rules are only good if you want to ensure portable code, some are simply broken and some stupid, etc. Having them properly classified would help us all. Tell me once you finish your ride, I'll merge changes back :-) Jan [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ to checkout issue: cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ On 18/01/13 17:06, Stéphane Ducasse wrote: Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef
[Pharo-project] What are the messages where we should always have a super send?
Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef
Re: [Pharo-project] What are the messages where we should always have a super send?
Hi Stef, while massaging SmallLint rules, you should also have look at Smalltalk/X version of SmallLint [1] as we have ported Pharo version and improved some rules. I have also added a tagging system. That's useful for some rules are only good if you want to ensure portable code, some are simply broken and some stupid, etc. Having them properly classified would help us all. Tell me once you finish your ride, I'll merge changes back :-) Jan [1] http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/refactoryBrowser/lint/ to checkout issue: cvs -d :pserver:c...@cvs.smalltalk-x.de:/cvs/stx co stx/goodies/refactoryBrowser/lint/ On 18/01/13 17:06, Stéphane Ducasse wrote: Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef
Re: [Pharo-project] What are the messages where we should always have a super send?
Yes, #setUp and #tearDown For #initialize, having a super may not be that necessary if you working on the class side. Alexandre On Jan 18, 2013, at 12:06 PM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi While looking at SmallLint rule, I saw a rule that ensures that a given method always performs a super send. Here is the current list: ^#(#release #postCopy #preBuildWith: #postOpenWith: #noticeOfWindowClose: #initialize postBuildWith:) and I'm cleaning the list because there are VW elements such as postBuildWith: but do we have some other to add? Stef -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
