On 30 January 2013 21:40, Camillo Bruni <[email protected]> wrote: > 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..)
imo.. a test methods in test cases should be labeled 'tests' while 'testing' is for methods like isA... so, if class is subclass of TestCase, you should use 'tests' , and if not, then 'testing' > 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. >> > > -- Best regards, Igor Stasenko.
