> 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
