>
> I do not get it. You want an identifier. Why is a brittle and
> obfuscated number better than the name of the class, which is already
> a proper identifier? If you do not want to rely directly on a class
> reference, you can store it as a symbol.
sure this is not the problem numbers solve. We want to have no impact because
of class name change.
> If you keep the numbering,
> you will immediately get into numbering issues as soon as people will
> start writing their own rules.
Normally not because number should be unique and should never change. But I see
your point
After we have a version number when we change a rule
for example rule 1 version 1 is different from rule 1 version 2
How you scenario behave in presence of class renaming?
Our is stable but indeed people can add number that clashes with existing ones.
Now we should have a rule stating that rule should have unique id.
>>> - In the rule methods, you are storing strings. This means that when
>>> someone renames a rule, the code in there will not be updated. Why not
>>> store this information as normal code and use symbols that can be queried?
>>
>> I do not get it? It is normal code no?
>> You mean symbols instead of strings.
>
> I mean you are currently storing the following in a rule exception:
> rule24V1FalsePositive
> ^ #(#('(RGMethodDefinition className: ''RGClassDefinitionTest''
> selector: #testReadFrom isMetaSide: false)'
> #'2012-04-02T11:31:59.933+02:00') )
>
> This an array of strings, not code. I was wondering why it would not
> be possible to be code directly.
because we do not want to store information that force us to have ring loaded.
Cheers,
> Doru
>
>
>> We will the issues.
>>
>>
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>
>>> On 6 Apr 2012, at 09:51, Simon Allier wrote:
>>>
>>>> Hi pharoers
>>>>
>>>> Since a couple of months the Pharo team has been working on improving the
>>>> support for rules checking and in particular the handling of false
>>>> positives (there is nothing more boring that to get all the time the same
>>>> warnings that we know are not adequate).
>>>> We added a manifest mechanism to manage the false/true positive of
>>>> SmallLint, the rule checker of Pharo. A manifest is a class that contains
>>>> meta data. In the future we may add package license and package
>>>> documentation. This data is stored in methods on the meta side of the
>>>> class. So, manifest can be versioned in Monticello and not lost. There is
>>>> one manifest per package.
>>>>
>>>> It possible to use SmallLint with Manifest using the Critics Browser
>>>> (menuWorld > Tool > CriticBrowser). With the Critics browser you can
>>>> inspect violations of rules and mark them as false positive or true
>>>> positive (ToDo) and see previous warnings flagged as false positives or
>>>> toDo.
>>>> In addition all the logic of the browser has been developed so that the
>>>> manifest can be saved within the package without adding dependencies.
>>>> We will continue to improve the Browser. In addition we will run SmallLint
>>>> rules to all the Pharo packages and the rules checking will be part of the
>>>> package validation. We want the community to use rule checking for real so
>>>> that we all improve.
>>>>
>>>> Simon and Stef
>>>>
>>>> Gofer
>>>> new
>>>> url: 'http://www.squeaksource.com/PharoTaskForces';
>>>> package: 'ConfigurationOfManifest';
>>>> load.
>>>> ((Smalltalk at: #ConfigurationOfManifest) project version: #stable) load
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Not knowing how to do something is not an argument for how it cannot be
>>> done."
>>>
>>>
>>
>>
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>
