On Tue, Nov 24, 2015 at 11:45 PM, Yuriy Tymchuk <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 > 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 > >