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