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