With the following (broken) definition printOn: 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? Stef
On 22 Nov 2015, at 16:20, stepharo <stepharo@free.fr> wrote:
With the following (broken) definition
printOn: aStream super printOn: aStream aStream nextPutAll: '(', faces printString , â)'
So, itâs broken because of the missing â.â. That means the message sent is #printOn:nextPutAll:.
I got this strange rule:
Rewrite super messages to self messages when both refer to same method
Perfectly reasonable. The rule says that in this context it doesnât effectively make a difference wether you send #printOn:nextPutAll: to super *or* to self. *But* from an aesthetic point of view (at least) self is better than super.
I do not get it and it looks really suspicious to me. Any suggestions?
I guess you were expecting âSends different superâ (at least I would). I think those two rules are complementary. But âSends different superâ would probably be enough to cover both cases. Not 100% sure though. Cheers, Max
Stef
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
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. 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
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" 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
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 : "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." ? 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
Essentially there should be 3 things: 1) clear name like: 'super' should receiver the same message (or similar). 2) good rationale explaining that you have to send the message to self and then either override it or let it run from supper, as this allows better flexibility. 3) make an automate fixing (as it is trivial). It should be doable by rewrite rules I suppose, but what annoys me is that when you use them, you donât have the matched string, nor the interval, so you cannot highlight it⦠Anyway, it is on my todolist. Cheers. Uko
On 24 Nov 2015, at 09:32, 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 : "'super' should call the same selector. Send different selector to 'self' then use 'super' in this one." ?
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
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. 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
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 <mailto: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
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
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
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
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 <mailto: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
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
yuriy could you improve the explanation of the rule? 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.
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
Yes, thanks Stef, itâs really important to report bad explanation, because I work with rules all the time and so know then by heart. I will improve this one, also let me know if there are more strange rationales. Cheers, Uko
On 23 Nov 2015, at 22:20, stepharo <stepharo@free.fr> wrote:
yuriy could you improve the explanation of the rule?
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.
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
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.
No really because I forgot on purpose the period. Now the explanation could be really improved. It could say Since you are not redefining printOn: nextPutAll:, it may be better not to use super. This would be a lot more understandable for newbies.
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
On 22 Nov 2015, at 16:20, stepharo <stepharo@free.fr> wrote:
printOn: aStream super printOn: aStream aStream nextPutAll: '(', faces printString , ')'
<being pedantic> And this is inefficient and mixes patterns. aStream << '('; print: faces; << ')' or aStream nextPut: $(; print: faces; nextPut: $) I think it is not a good idea to do string concatenation when you have to write to a stream anyway. </being pedantic>
Le 22/11/15 19:01, Peter Uhnák a écrit :
printOn: aStream super printOn: aStream aStream nextPutAll: '(', faces printString , ')' Because you forgot dot after the first line.
This is why I always use autoformatting to catch these kind of stupid mistakes (happens to me a lot).
Yes I did it on purpose. This is part of the "learning from mistakes" lecture I'm writing. Now the explanation of the rule is plain bad.
participants (8)
-
Ben Coman -
Marcus Denker -
Max Leske -
Nicolas Anquetil -
Peter Uhnák -
stepharo -
Sven Van Caekenberghe -
Yuriy Tymchuk