> On 24 Nov 2015, at 17:29, Ben Coman <b...@openinworld.com> wrote: > > On Tue, Nov 24, 2015 at 11:45 PM, Yuriy Tymchuk <yuriy.tymc...@me.com > <mailto:yuriy.tymc...@me.com>> wrote: >> >> On 24 Nov 2015, at 14:10, Ben Coman <b...@openinworld.com> wrote: >> >> On Tue, Nov 24, 2015 at 4:32 PM, Nicolas Anquetil >> <nicolas.anque...@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.den...@inria.fr> wrote: >> >> >> On 22 Nov 2015, at 12:20, stepharo <steph...@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