On 24 Nov 2015, at 17:29, Ben Coman <btc@openinworld.com> wrote:

On Tue, Nov 24, 2015 at 11:45 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

On 24 Nov 2015, at 14:10, Ben Coman <btc@openinworld.com> wrote:

On Tue, Nov 24, 2015 at 4:32 PM, Nicolas Anquetil
<nicolas.anquetil@inria.fr> wrote:
On 23/11/2015 22:14, stepharo wrote:
Le 22/11/15 22:11, Yuriy Tymchuk a ��crit :

Hi.

The rule is correct. Sending a different message to super may be
confusing. In this case you are in ��printOn:�� method and you are sending
��printOn:nextPutAll:�� to super. The idea is that you have to send
��printOn:nextPutAll:�� to self and then either it will invoke the super one,
you there will be an overridden method in your current class.

exactly but do you expect a newbie to understand anything with the current
explanation?
I do not.

Rewrite super messages to self messages when both refer to same method"

What about :

Sorry :) both of these make my head hurt. I think Stef's was clearer.
The useful part there is that it reports the actual identifier causing
the problem, which makes it more obvious this is not what was meant,
from which even a newbie may infer the missing period.

"'super' should call the same selector. Send different selector to 'self'
then use 'super' in this one."
?

btw, is this just commonly how super is used, or is it really bad to
call a different super method?
I'm sure I've done that on occasion.

It makes harder to extend your code. Because if method `a` calls method `b`,
then even if method `b` is not defined in your class, I can subclass and
redefine method b. Otherwise I have to subclass and redefine `a` although
`a` is fine, but I want to run my `b` and not the one of superclass.

Uko

Thanks Uko. I was considering a case where my new subclass has
redefined 'b', but I want my 'a' to avoid my 'b' and use the
superclass one.

(Sorry I can't remember the use case)
cheers -ben

Hi,

no rule is perfect, and there are definitely cases that work the other way around. But we try to focus on the best practices.

Also I think this influences the maintainability of code. Because in the suggested by the rule, you have method `a` with one responsibility and it uses method `b` with another responsibility. Now when you call method `b` from the super class, all logic becomes more complicated.

Uko

cheers -ben

or:

"should not send a different message to super (send different message to
self and then call super from it)"
?

nicolas

Sucks

Secondly, there is an issue with ��sends unkown selector��. I��ve also
noticed it recently. I think that it happens because the rule has a special
cace, and I messed up something with refresh. This is the next thing on my
TODO list.

Cheers.
Uko

On 22 Nov 2015, at 16:33, Marcus Denker <marcus.denker@inria.fr> wrote:

On 22 Nov 2015, at 12:20, stepharo <stepharo@free.fr> wrote:

With the following (broken) definition

: aStream
super printOn: aStream
aStream nextPutAll: '(', faces printString , ')'

I got this strange rule:

Rewrite super messages to self messages when both refer to same
method

I do not get it and it looks really suspicious to me.
Any suggestions?

The rule is meant to catch the case when when ��super�� can be ��self�� as
there is no #printOn:
defined in the class.

But here it looks like it is wrong: it would be an infinite loop.

I think it could be related to this other bug: I have seen that the
rules are not correctly updated
when you add methods. (I wanted to add an issue for that but did not
yet). E.g. I often get
a ��sends unkown selector�� for self sends and then I check ��> method is
there, I just added it!

So here this means that you added a new printOn:, the rules do not
update, and it thinks
that there is no printOn:.

So the real bug is that added methods need to be taken into account by
QA.

Marcus

--
Nicolas Anquetil
RMod team -- Inria Lille