Oh, ok ! Thank you Guillermo ! On 23 April 2015 at 11:58, Guillermo Polito <[email protected]> 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 > <[email protected]> escribió: >> >> Stef, >> >> where is "the tool"? >> >> Norbert >> >> > Am 23.04.2015 um 08:01 schrieb stepharo <[email protected]>: >> > >> > 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 <[email protected]> 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
