Hi guys, Iâm wandering if #canUnderstand: is implemented in a right way. I has exactly the same implementation as #canPerform:, so I wander if itâs a part of renaming process or one of the methods is not doing what they should. Uko
Hi Yuriy, If I remember well, originally, there was #canUnderstand: that checked if a method with the given selector is present in the class hierarchy while #canPerform: was also checking that it is not a subclassResponsibility, an explicitRequirement or a shouldBeDefined method. Right now, both does the latter, I don't know why. I had trouble with this change because it broke some critics rules ("message sent but not implemented" for ex). Camille On 9 juil. 2014, at 16:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm wandering if #canUnderstand: is implemented in a right way. I has exactly the same implementation as #canPerform:, so I wander if itâs a part of renaming process or one of the methods is not doing what they should.
Uko
On 09 Jul 2014, at 17:16, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Yuriy,
If I remember well, originally, there was #canUnderstand: that checked if a method with the given selector is present in the class hierarchy while #canPerform: was also checking that it is not a subclassResponsibility, an explicitRequirement or a shouldBeDefined method. Right now, both does the latter, I don't know why.
Maybe someone knows. Letâs wait a bit :)
I had trouble with this change because it broke some critics rules ("message sent but not implemented" for ex).
Yes, Iâve started to investigate https://pharo.fogbugz.com/f/cases/13521/RBMissingSubclassResponsibilityRule-... and found out that there is a problem with #canUnderstand: Uko
Camille
On 9 juil. 2014, at 16:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm wandering if #canUnderstand: is implemented in a right way. I has exactly the same implementation as #canPerform:, so I wander if itâs a part of renaming process or one of the methods is not doing what they should.
Uko
Look like the same problem is present in Pharo 3. As far as I can understand this method was changed by: Name: Traits-EstebanLorenzano.546 Author: EstebanLorenzano Time: 11 July 2013, 5:13:16.382835 pm UUID: 98c02312-1412-4887-9f5d-b4899a43c85b Ancestors: Traits-EstebanLorenzano.544 - freezed 11151 version Any ideas why? Esteban? Uko On 09 Jul 2014, at 17:19, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 09 Jul 2014, at 17:16, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Yuriy,
If I remember well, originally, there was #canUnderstand: that checked if a method with the given selector is present in the class hierarchy while #canPerform: was also checking that it is not a subclassResponsibility, an explicitRequirement or a shouldBeDefined method. Right now, both does the latter, I don't know why.
Maybe someone knows. Letâs wait a bit :)
I had trouble with this change because it broke some critics rules ("message sent but not implemented" for ex).
Yes, Iâve started to investigate https://pharo.fogbugz.com/f/cases/13521/RBMissingSubclassResponsibilityRule-... and found out that there is a problem with #canUnderstand:
Uko
Camille
On 9 juil. 2014, at 16:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm wandering if #canUnderstand: is implemented in a right way. I has exactly the same implementation as #canPerform:, so I wander if itâs a part of renaming process or one of the methods is not doing what they should.
Uko
And there was this issue: https://pharo.fogbugz.com/f/cases/12357/ On 10 Jul 2014, at 09:42, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Look like the same problem is present in Pharo 3.
As far as I can understand this method was changed by:
Name: Traits-EstebanLorenzano.546 Author: EstebanLorenzano Time: 11 July 2013, 5:13:16.382835 pm UUID: 98c02312-1412-4887-9f5d-b4899a43c85b Ancestors: Traits-EstebanLorenzano.544
- freezed 11151 version
Any ideas why? Esteban?
Uko
On 09 Jul 2014, at 17:19, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 09 Jul 2014, at 17:16, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Yuriy,
If I remember well, originally, there was #canUnderstand: that checked if a method with the given selector is present in the class hierarchy while #canPerform: was also checking that it is not a subclassResponsibility, an explicitRequirement or a shouldBeDefined method. Right now, both does the latter, I don't know why.
Maybe someone knows. Letâs wait a bit :)
I had trouble with this change because it broke some critics rules ("message sent but not implemented" for ex).
Yes, Iâve started to investigate https://pharo.fogbugz.com/f/cases/13521/RBMissingSubclassResponsibilityRule-... and found out that there is a problem with #canUnderstand:
Uko
Camille
On 9 juil. 2014, at 16:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm wandering if #canUnderstand: is implemented in a right way. I has exactly the same implementation as #canPerform:, so I wander if itâs a part of renaming process or one of the methods is not doing what they should.
Uko
Ok, so according to BehaviorTest>>#testCanUnderstand, #canUnderstand should return false if the method has subclassResponsibility. On the other hand #canPerform: does not have any test cases and is used only once in RBExplicitRequirementMethodsRule. Maybe this means that #canUnderstand started to do the job of #canPerform and we donât have any method that checks if given class has defined method with a given name without checking whether it has subclassResponsibility or explicitRequirement. Uko On 10 Jul 2014, at 09:52, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
And there was this issue: https://pharo.fogbugz.com/f/cases/12357/
On 10 Jul 2014, at 09:42, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Look like the same problem is present in Pharo 3.
As far as I can understand this method was changed by:
Name: Traits-EstebanLorenzano.546 Author: EstebanLorenzano Time: 11 July 2013, 5:13:16.382835 pm UUID: 98c02312-1412-4887-9f5d-b4899a43c85b Ancestors: Traits-EstebanLorenzano.544
- freezed 11151 version
Any ideas why? Esteban?
Uko
On 09 Jul 2014, at 17:19, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 09 Jul 2014, at 17:16, Camille Teruel <camille.teruel@gmail.com> wrote:
Hi Yuriy,
If I remember well, originally, there was #canUnderstand: that checked if a method with the given selector is present in the class hierarchy while #canPerform: was also checking that it is not a subclassResponsibility, an explicitRequirement or a shouldBeDefined method. Right now, both does the latter, I don't know why.
Maybe someone knows. Letâs wait a bit :)
I had trouble with this change because it broke some critics rules ("message sent but not implemented" for ex).
Yes, Iâve started to investigate https://pharo.fogbugz.com/f/cases/13521/RBMissingSubclassResponsibilityRule-... and found out that there is a problem with #canUnderstand:
Uko
Camille
On 9 juil. 2014, at 16:50, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm wandering if #canUnderstand: is implemented in a right way. I has exactly the same implementation as #canPerform:, so I wander if itâs a part of renaming process or one of the methods is not doing what they should.
Uko
participants (2)
-
Camille Teruel -
Yuriy Tymchuk