Remove rule "References an abstract class"
This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when: - the abstract class takes care of choosing the concrete class to instantiate - the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object) I propose to remove this rule which has never been useful for me. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Hi. First of all: thank you for the feedback Damien! It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful. Uko
On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou@inria.fr> wrote:
This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when:
- the abstract class takes care of choosing the concrete class to instantiate
- the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object)
I propose to remove this rule which has never been useful for me.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
You can probably remove it directly from Pharo instead https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule Peter On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi.
First of all: thank you for the feedback Damien! It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful.
Uko
On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou@inria.fr> wrote:
This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when:
- the abstract class takes care of choosing the concrete class to instantiate
- the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object)
I propose to remove this rule which has never been useful for me.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Ok, it can be removed from Pharo⦠I still find it useful as well as missing yourself, but I can keep track of then individually :)
On 17 Sep 2015, at 09:39, Peter Uhnák <i.uhnak@gmail.com> wrote:
You can probably remove it directly from Pharo instead https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule <https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule>
Peter
On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote: Hi.
First of all: thank you for the feedback Damien! It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful.
Uko
On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou@inria.fr <mailto:damien.cassou@inria.fr>> wrote:
This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when:
- the abstract class takes care of choosing the concrete class to instantiate
- the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object)
I propose to remove this rule which has never been useful for me.
-- Damien Cassou http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/>
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
yes the problem with rules comes when the rule add more noise than is helpful. If you do not want to remove this rule because it is useful in some cases, maybe the rule could check only these specific situations to do not add noise in others. Le 17 sept. 2015 à 10:37, Yuriy Tymchuk a écrit :
Ok, it can be removed from Pharo⦠I still find it useful as well as missing yourself, but I can keep track of then individually :)
On 17 Sep 2015, at 09:39, Peter Uhnák <i.uhnak@gmail.com> wrote:
You can probably remove it directly from Pharo instead https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule
Peter
On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote: Hi.
First of all: thank you for the feedback Damien! It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful.
Uko
On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou@inria.fr> wrote:
This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when:
- the abstract class takes care of choosing the concrete class to instantiate
- the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object)
I propose to remove this rule which has never been useful for me.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image? Uko
On 17 Sep 2015, at 12:11, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
yes the problem with rules comes when the rule add more noise than is helpful. If you do not want to remove this rule because it is useful in some cases, maybe the rule could check only these specific situations to do not add noise in others.
Le 17 sept. 2015 à 10:37, Yuriy Tymchuk a écrit :
Ok, it can be removed from Pharo⦠I still find it useful as well as missing yourself, but I can keep track of then individually :)
On 17 Sep 2015, at 09:39, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
You can probably remove it directly from Pharo instead https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule <https://pharo.fogbugz.com/f/cases/15858/review-rule-RBAbstractClassRule>
Peter
On Thu, Sep 17, 2015 at 9:09 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote: Hi.
First of all: thank you for the feedback Damien! It makes sense, the rule also has higher amount of negative feedback. I will remove it from QA, let it stay in the image, it actually can be useful.
Uko
On 17 Sep 2015, at 06:49, Damien Cassou <damien.cassou@inria.fr <mailto:damien.cassou@inria.fr>> wrote:
This lint rule pops up all the times and my code is always ok. I typically have to reference an abstract class when:
- the abstract class takes care of choosing the concrete class to instantiate
- the abstract class takes care of some shared variable for its subclasses (e.g., a cache or an shared external object)
I propose to remove this rule which has never been useful for me.
-- Damien Cassou http://damiencassou.seasidehosting.st <http://damiencassou.seasidehosting.st/>
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
On 17 Sep 2015, at 12:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image?
Because it is wrong? If we keep it, people will see it when they use the Critic Browser⦠what would be the reason to keep a rule that everyone things is not good? Marcus
Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change. Of course they are only a few of them, but as you are not able to set up what rules you want to have in QualityAssistant, it makes sense to remove ones that the majority does not like. But in critics browser we can specify which rules you want to run. So I donât see a need in a complete removal. Yes, maybe form UX perspective critic browser should have some button like: âRun only the important onesâ⦠Uko
On 17 Sep 2015, at 13:43, Marcus Denker <marcus.denker@inria.fr> wrote:
On 17 Sep 2015, at 12:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Well, what I am saying is that I agree that people should not be bothered with this rule by QualityAssistant. But why we should remove the rule from the image?
Because it is wrong? If we keep it, people will see it when they use the Critic Browser⦠what would be the reason to keep a rule that everyone things is not good?
Marcus
On 17 Sep 2015, at 14:08, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change
When I learned something than this: Whatever you do, someone will think it is wrong. The largest mistake that you can do is to only do things that nobody objects to⦠because the only thing that fulfils that is to do nothing. Marcus
Well, for me itâs ok. Then I donât have to create a new version in conf :).
On 17 Sep 2015, at 14:17, Marcus Denker <marcus.denker@inria.fr> wrote:
On 17 Sep 2015, at 14:08, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Because people can choose in critic browser what they want to see. At least this is my opinion. As a sneak peek to the survey results I can say that there are people who find the removed of âmissing yourselfâ rule as a negative change
When I learned something than this: Whatever you do, someone will think it is wrong. The largest mistake that you can do is to only do things that nobody objects to⦠because the only thing that fulfils that is to do nothing.
Marcus
participants (5)
-
Christophe Demarey -
Damien Cassou -
Marcus Denker -
Peter Uhnák -
Yuriy Tymchuk