Thanks Uko. I'll keep that in mind. cheers On Wed, Nov 25, 2015 at 1:37 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
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