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 < norbert@hartl.name> escribió:
Stef,
where is "the tool"?
Norbert
Am 23.04.2015 um 08:01 schrieb stepharo <stepharo@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 <stepharo@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