Hi Cyril, I’ve checked the problem. It could be indeed easier if the rule pointed to it :).
So you have PRFileInclusion>>replace: and it is identical (not taking empty lines into account) to PRTransformer>>replace:. So the rule is correct. You override a method with an identical method. Uko > On 23 Apr 2015, at 12:48, Cyril Ferlicot <cyril.ferli...@gmail.com> wrote: > > I changed that but i still have the warning from quality assistant. > > On 23 April 2015 at 12:44, Cyril Ferlicot <cyril.ferli...@gmail.com> wrote: >> Oh, ok ! Thank you Guillermo ! >> >> On 23 April 2015 at 11:58, Guillermo Polito <guillermopol...@gmail.com> >> wrote: >>> Hi Cyril, >>> >>> Your problem is caused because abstract methods should be marked with >>> "subclassResponsibility" and not "shouldBeImplemented". >>> >>> - shouldBeImplemented means "this is a method I did not implement yet, I >>> should replace *this* method with another implementation" >>> - subclassResponsibility means "my subclasses should implement a method with >>> this same selector" >>> >>> The tools recognize the first as a normal "concrete" method and the second >>> as an abstract method. >>> >>> El jue., 23 de abr. de 2015 a la(s) 10:15 a. m., Norbert Hartl >>> <norb...@hartl.name> escribió: >>>> >>>> Stef, >>>> >>>> where is "the tool"? >>>> >>>> Norbert >>>> >>>>> Am 23.04.2015 um 08:01 schrieb stepharo <steph...@free.fr>: >>>>> >>>>> Two things: >>>>> >>>>> One: >>>>> We paid a guy to work on a tool to help us identifying dependencies, The >>>>> tool works well is fast. >>>>> if this tool would be in the image, everybody could check that there are >>>>> bad dependencies in his >>>>> code (and there are many around in nearly anybody's code). >>>>> No we prefer that me, pavel, and guille run it and fight with this >>>>> instead of making sure that >>>>> when you commit we get some feedback like: "oh strange that this package >>>>> is bound with this one". >>>>> This tool breaks when we do change in the image and I nicely (stupidly I >>>>> would say) maintain it. >>>>> >>>>> Two: >>>>> Our process is not great to manage external packages and we will add >>>>> more. >>>>> Sure it sounds like the right things to do, especially now. >>>>> >>>>> So to me it simply means that we are not serious and convinced about >>>>> modularity. >>>>> >>>>> But this is great, I'm reconsidering what I will do in Pharo so you give >>>>> me good indication >>>>> that I should not continue the way I was thinking. And no need to think >>>>> that I'm emotional >>>>> I'm not. I'm thinking about why hell I'm doing all this. >>>>> >>>>> Stef >>>>> >>>>> Le 22/4/15 21:27, Marcus Denker a écrit : >>>>>>> On 22 Apr 2015, at 20:22, stepharo <steph...@free.fr> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Le 22/4/15 13:23, Esteban Lorenzano a écrit : >>>>>>>> this is so good. >>>>>>>> what about integrate it to Pharo? >>>>>>> No. People should start to think modular. >>>>>>> No more external tools loaded by default. >>>>>>> Better invest in "add a startup preference" functionality in the >>>>>>> configurationBrowser. >>>>>>> >>>>>>> Why we do not integrate the excellent tool of baptiste that would show >>>>>>> to people >>>>>>> when they are creating package mess? Because of the same reason. >>>>>>> >>>>>> But the Pharo that we download should be the Pharo we use. >>>>>> >>>>>> We tried the other back in Pharo1.0: Do you remember how we fixed with >>>>>> lots >>>>>> care all details, but then, everyone was using a different image, and >>>>>> all the >>>>>> details there where not fixed and all work was done double? >>>>>> >>>>>> If we do not make the Pharo that is downloaded to be that was is used, >>>>>> we will have >>>>>> that again. >>>>>> >>>>>> I don’t want everything in the image, but what everyone is supposed to >>>>>> be using should >>>>>> be there without needing an additional step. >>>>>> >>>>>> Marcus >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> >> >> -- >> Cheers >> Cyril Ferlicot > > > > -- > Cheers > Cyril Ferlicot >
