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 > >> > >> > >> > >> > > > > > > >
