Cool
Camillo can I see the code?
I was planning to look for the old autocategoriser.
Stef
> I just wrote a simple classifier which is going to be used in Nautilus.
> Basically it is an extensions of the existing code.
>
> Methods are classified using the following rules:
>
> 1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..)
could we have initialize and not initialize-release
> 2. getters and setters of instance variables
> 3. know protocols of super implementors
> 4. gather all implementors in the system and choose the most used protocol.
>
> I guess that will cover most stuff, of course known prefixes will have to be
> extended...
>
>
> On 2013-01-30, at 20:52, Chris Muller <[email protected]> wrote:
>
>>> To be honest I have problems understanding why method categorization is so
>>> important.
>>
>> It provides a look into the mind of the author.
>>
>>> Often I don't care a single bit about categories because I don't understand
>>> them. I often categorize just to make lint happy :)
>>
>> Ha! I remember when I used to voluntarily submit myself to lint's
>> slavery. For a while I was putting in selectors to ignore or whatever
>> the filtering capability it had -- until one day I said, "enough".
>> Since then I mostly just check for "Bugs" -- let lint work for ME.
>> Perhaps a better approach to help you relax would be to remove that
>> particular Lint rule..? :) Ahh, freedom. :)
>>
>> Categories they are "integrated documentation" and, the fact that some
>> methods remain 'as yet unclassified' IS meaningful -- it indicates
>> that the class is either private or single-purpose. There are a lot
>> of "code elements" in the system (classes, methods, categories,
>> packages, etc.) and so sometimes, as you said, classes are simple
>> enough that additional category elements are not needed.
>>
>> Categories are the domain of humans, not machines. They're for the
>> writer to communicate to the readers. Auto-categorization does not
>> increase the effectiveness of categories -- in fact I think it would
>> dilute it.
>>
>>> What is the use? Declaring usage patterns?
>>
>> Yes.
>>
>>> .. Declaring visibility?
>>
>> Yes.
>>
>>> Use as method extensions marker?
>>
>> Yes.
>>
>> anything you like just classify? I can understand that it can help
>> making the access of certain methods of a class easier. But that is
>> particular true for classes with a lot of methods. Most of the classes
>> are rather small. In most of my own developments I would consider most
>> huge classes a design problem in my code. So I would try to fix that.
>>> And finally it is not easy to learn about them because the browser is not
>>> helping. If you browse through the methods of a class the category pane
>>> doesn't get updated. So even if I want to learn by getting used to them it
>>> is hard.
>>
>> Two ways to do that (at least in Pharo 1.4, not sure about 2.0).
>>
>> 1) With focus on the methods list, press Shift+Command+C.
>> 2) Turn on System | Settings | Code browsing | Show annotation panes.
>>
>>> I would make the none categorized term weaker by naming it "uncategorizied"
>>> so at least I have the change to deliberately not categorizing my methods
>>> without being annoyed by someones opinion about what is essential.
>>
>> +1. Because "as yet" implies it "will" or "needs" to be classified,
>> which isn't always true.
>>
>
>
