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 : "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." ? 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