Hi Stef,

�it is great to see that you are using SmallLint to check for errors in Pharo. I the development process we had in a project I participated, we had a step where you had to run SmallLint and you could not commit code with smallLint errors and for some packages with possible errors.�

�Becuase SmallLint generates a quite a lot false positives, we developed at that time (it was around 2004) something we called "ExpectedSmallLintErrors" that we use to document those false positives and therefore be able to commit the changes (the documentation was smalltalk code of course that included a reason and an author). The interesting thing about this kind of doc. was that if the false positive went away you had to remove the related "expected error", so it worked both ways.

�We solved the problems you mentioned about subclass responsibility and others similars, all with VisualAge

�It was really cool and it help us to catch and prevent a lot of errors. We ported it to Pharo (or Squeak at that time) a long time ago, but I cannot find the project on SqueakSource... I remember that Lukas had implemented something similar using pragmas but it lacked some features that we supported that I don't remember now :-)

�Anyway, I'm really happy to see that the Pharo team is using SmallLint and I think you should put it as a step in the development process, and I also recommend to you to have some "interesting" way of documenting false positive because if not you will end up not using it... at least that was my experience.

Bye,

Hernan.

On Tue, Jan 22, 2013 at 8:59 PM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:

> Well. I've written the tag support, so let's make it simple, MIT.
> I may export a changeset with that code for you, if you like.

Else I will just go over them and it will help me to understand. I think that this is not difficult.

> For rules written by CG I'm not sure. You should check with him.
> But I think it won't be a problem given that you preserve all
> the signatures and #documentation and #version_XXX methods
> (we use them to track changes in the source).
>
> However, what I planned (and run out of time :-) is to make
> tag a first class object with name (symbol) description etc
> and have class methods to create them. Then one may define and
> describe meaning of the tag in an extension method.
> Also, the selection/rejection logic could dispatch back on
> the tag instance so you may then create fancy dynamic tags
> (like #portability that automatically includes everything tagged
> as #pharo #squeak #stx #va, for instance or whatever.
>
> I might hack it later this week, if you would include it into
> your version (otherwise I've more important things to do :-)

I imagine well.
Let us keep it simple. Simple tags with a little class comments are good enough :)

>
> Cheers
>
> On 22/01/13 19:32, St�phane Ducasse wrote:
>> Jan
>> what is the license of your tags and other code?
>>
>> Stef
>>
>> On Jan 22, 2013, at 3:45 PM, Jan Vrany wrote:
>>
>>> On 22/01/13 18:22, St�phane Ducasse wrote:
>>>> Hi
>>>>
>>>> I'm running the rule RBSubclassResponsibilityNotDefinedRule that
>>>>
>>>> � �Checks that all subclassResponsibility methods are defined in all leaf classes.
>>>>
>>>> Now the results display the sender of ^ subclassResponsibility but I have to manually find the
>>>> problems. I would be better to report the violations. Of course this is not that simple: returning a class and missing method.
>>>>
>>>> But this would be much better. Jan did you do that in your version?
>>>
>>> Good point. Yes, since now we do that :-)
>>>
>>> Jan
>>>
>>>>
>>>> Stef
>>>>
>>>
>>>
>>
>>
>>
>
>

--

Hern�n Wilkinson
Agile Software Development, Teaching & Coaching

Phone: +54 - 011 -�6091 - 3125
Mobile: +54 - 911 - 4470 - 7207
email: hernan.wilkinson@10Pines.com
site:�http://www.10Pines.com

Address: Alem 693, Floor 5 B, Buenos Aires, Argentina