=== on 21 Oct 2014, 14:05:14 Nicolas Peru wrote:
Ok for me. Doable as is.

=== on 25 Nov 2014, 11:22:03 Freddy Mallet wrote:
My 2 cents [~ann.campbell.2]:

* Very valuable rule
* I would replace the title by : "In a hierarchy of classes, method signatures should not differ only based on fully qualified names"
* The compliant solution is for me misleading because according to this solution having a doSomething() method taking a fruit.Pear parameter was done on purpose. The same way, I would remove the following sentences from the description: ""If the intent is truly for the child class to handle the same-name object from another package, then the method should be renamed to prevent confusion. Otherwise the import or fully-qualified class name should be corrected.

=== on 2 Dec 2014, 13:57:18 Ann Campbell wrote:
\[~freddy.mallet] I've updated the title, but your second point is in my mind the point of the rule - if you need to deal with a class that differs only by package, you must make it explicit & must not make the method _look_ like an override.

=== on 4 Dec 2014, 10:22:39 Freddy Mallet wrote:
When this pattern occurs [~ann.campbell.2], I would bet that in 99% of the time this is not done on purpose and this is really a bug (to have imported the wrong class). With your example [~ann.campbell.2], I've the feeling that you're covering the remaining 1% -> done on purpose to import another class with exactly the same method signature.

=== on 27 Feb 2015, 21:17:16 Freddy Mallet wrote:
@Ann, what about linking this rule to \http://cwe.mitre.org/data/definitions/628.html ?

=== on 2 Mar 2015, 12:52:48 Ann Campbell wrote:
\[~freddy.mallet] IMO the CWE, which is about method invocations, isn't a fit with this rule, which is about method declarations.


But I have added it to RSPEC-961, and RSPEC-930.

=== on 12 Jun 2015, 13:07:11 Ann Campbell wrote:
CodePro: Hiding Inherited Static Methods

=== on 12 Jun 2015, 15:39:44 Ann Campbell wrote:
CodePro: Overriding Private Method

=== on 4 Aug 2015, 20:13:37 Ann Campbell wrote:
\[~tamas.vajk] this rule is related to FxCop's DoNotDecreaseInheritedMemberVisibility but doesn't cover quite the same ground (I don't think you _can_ decrease visibility in an override in Java). Do you want to expand the scope slightly for C# & map this?

=== on 5 Aug 2015, 13:05:15 Tamas Vajk wrote:
\[~ann.campbell.2] I think C# shouldn't be targeted by this rule. In C# you can't accidentally override or accidentally not override a method. You need to use the ``++override++`` keyword, and not just simply use the same signature. The FxCop rule says that if you are not overriding but redefining a method you should still not decrease the visibility.

