In st-80 these were protocols and the name make you think of it differently. If you want to continue thinking of it in term of category, then I understand your miss-conception. I'm curious to know when the term category was introduced... Maybe with Monticello where it means 'Package'? Clever hacks sometimes are not that clever...
Nicolas 2013/1/30 Norbert Hartl <[email protected]> > > Am 30.01.2013 um 22:03 schrieb Nicolas Cellier < > [email protected]>: > > First, these are not categories. categories are for classes. > These are protocols. > > > Well, that's one reason I took the term "uncategorized". If I take the > context menu in the category (!) pane I see > > > So it looks to me that pharo has the notion of categories for organizing > methods. > > > A protocol is like an interface, or you can view it as services > offered by the instances of this class... > For example take a look at Number you have > 'comparing', is a very generic service, so that any object can be in a set > numbers have this property to have full order, so they offer a bit > more than = and hash > 'printing' a very generic Object protocol too for interacting > (inspectors, debuggers...) > 'arithmetic' is some more specialized service offered by numbers > 'mathematical functions' too. > > The category is a service for humans made by humans. The methods in e.g. > "comparing" would work the same without a category. I think we can agree on > the fact that relying on categories in code is mostly something not > desirable. > > If the classification helps a lot, IMHO it's not only related to the > number of messages. > It helps to declare/discover which service will be offered, and those > can be completely transversal (printing vs comparing). > > 'private' has a value too, as there is no service to expect here... > > So I have to disagree. I see these as essentials. > > I did not decline that categories _can_ be useful and in fact they are. > I'm also inclined to say that it is a good thing having all methods > categorized in the distributed pharo image. So lint rules and such testing > is good. But at the same time I don't see a point in enforcing it for > everyone by choosing a stronger or even insulting term (at that point I > decided to reply) for uncategorized methods. > > Norbert > > > Nicolas > > 2013/1/30 Norbert Hartl <[email protected]>: > > > Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse <[email protected] > >: > > Hi guys > > I spend my time recategorizing methods. > > I would like the change the intention of 'as yet unclassified' because > this is a PLAGUE. > It is like throwing papers on the floor. > So we should have a different name to indicate that it should be fixed. > > > Any ideas? > > 'you are a dirty programmer - change me' > > > To be honest I have problems understanding why method categorization is so > important. Often I don't care a single bit about categories because I don't > understand them. I often categorize just to make lint happy :) > What is the use? Declaring usage patterns? Declaring visibility? Use as > method extensions marker? 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. > > 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. > > my 2 cents, > > Norbert > > > >
<<Bildschirmfoto 2013-01-30 um 22.17.17.png>>
