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