30338 ----- 11428 Remove a buggy redundant test in FuelTests https://pharo.fogbugz.com/f/cases/11428 11417 Test for checking repeated code in superclasses must not watch in nativeBoost classes https://pharo.fogbugz.com/f/cases/11417 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tests-MarcusDenker.612.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Refactoring-Critics-MarcusDenk... http://smalltalkhub.com/mc/Pharo/Pharo30/main/FuelTests-MarcusDenker.333.dif...
On 2013-08-21, at 09:36, Marcus Denker <marcus.denker@inria.fr> wrote:
30338 -----
11428 Remove a buggy redundant test in FuelTests https://pharo.fogbugz.com/f/cases/11428
11417 Test for checking repeated code in superclasses must not watch in nativeBoost classes https://pharo.fogbugz.com/f/cases/11417
why do we exclude NativeBoost from this sanity check?
There are some problems in NativeBoost if a method does not belong to the class itself, i don't understand the problem very well but that is what Igor and Stef told me. 2013/8/21 Camillo Bruni <camillobruni@gmail.com>
On 2013-08-21, at 09:36, Marcus Denker <marcus.denker@inria.fr> wrote:
30338 -----
11428 Remove a buggy redundant test in FuelTests https://pharo.fogbugz.com/f/cases/11428
11417 Test for checking repeated code in superclasses must not watch in nativeBoost classes https://pharo.fogbugz.com/f/cases/11417
why do we exclude NativeBoost from this sanity check?
Thanks Sebastian, Stef/Igor more details please? On 2013-08-21, at 13:54, Sebastian Tleye <stleye@gmail.com> wrote:
There are some problems in NativeBoost if a method does not belong to the class itself, i don't understand the problem very well but that is what Igor and Stef told me.
2013/8/21 Camillo Bruni <camillobruni@gmail.com>
On 2013-08-21, at 09:36, Marcus Denker <marcus.denker@inria.fr> wrote:
30338 -----
11428 Remove a buggy redundant test in FuelTests https://pharo.fogbugz.com/f/cases/11428
11417 Test for checking repeated code in superclasses must not watch in nativeBoost classes https://pharo.fogbugz.com/f/cases/11417
why do we exclude NativeBoost from this sanity check?
There are some problems in NativeBoost if a method does not belong to the class itself, i don't understand the problem very well but that is what Igor and Stef told me.
Some methods are placeholder for generated code and the placeholder cannot be avoided and there is nothing wrong in the design. This is why such system wide tests should be replaced by rules that each package declare as false positive and adapt to the package own practice. Stef
On 2013-08-21, at 17:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
There are some problems in NativeBoost if a method does not belong to the class itself, i don't understand the problem very well but that is what Igor and Stef told me.
Some methods are placeholder for generated code and the placeholder cannot be avoided and there is nothing wrong in the design.
This is why such system wide tests should be replaced by rules that each package declare as false positive and adapt to the package own practice.
but that doesn't justify that the methods have the same contents, AFAIK this is what the test compares. And I still think form a outside viewpoint duplicated methods do not make sense at all, NativeBoost should be no exception there.
On Aug 21, 2013, at 5:44 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-08-21, at 17:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
There are some problems in NativeBoost if a method does not belong to the class itself, i don't understand the problem very well but that is what Igor and Stef told me.
Some methods are placeholder for generated code and the placeholder cannot be avoided and there is nothing wrong in the design.
This is why such system wide tests should be replaced by rules that each package declare as false positive and adapt to the package own practice.
but that doesn't justify that the methods have the same contents, AFAIK this is what the test compares.
so do you think that we should generate method value 'foo1' value 'foo2' value 'foo3' just to satisfy a test that does not apply?
And I still think form a outside viewpoint duplicated methods do not make sense at all, NativeBoost should be no exception there.
On 2013-08-21, at 17:59, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Aug 21, 2013, at 5:44 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-08-21, at 17:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
There are some problems in NativeBoost if a method does not belong to the class itself, i don't understand the problem very well but that is what Igor and Stef told me.
Some methods are placeholder for generated code and the placeholder cannot be avoided and there is nothing wrong in the design.
This is why such system wide tests should be replaced by rules that each package declare as false positive and adapt to the package own practice.
but that doesn't justify that the methods have the same contents, AFAIK this is what the test compares.
so do you think that we should generate method value 'foo1'
value 'foo2'
value 'foo3'
just to satisfy a test that does not apply?
I guess we can find another more creative solution, but yes, if it is in the kernel, I would suggest that we apply the same sane logics: - no/little code duplication - no/little use of #perform: / #doesNotUnderstand: magic If I see code that repeats the same method in it superclass I get confused since it breaks my assumptions about Pharo code.
participants (4)
-
Camillo Bruni -
Marcus Denker -
Sebastian Tleye -
Stéphane Ducasse