Essentially there should be 3 things:
1) clear name like: 'super' should receiver the same message (or similar).
2) good rationale explaining that you have to send the message to self and then either override it or let it run from supper, as this allows better flexibility.
3) make an automate fixing (as it is trivial). It should be doable by rewrite rules I suppose, but what annoys me is that when you use them, you don���t have the matched string, nor the interval, so you cannot highlight it���
Anyway, it is on my todolist.
Cheers.
Uko
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 AnquetilRMod team -- Inria Lille