2013/1/31 Stéphane Ducasse <[email protected]>: > > On Jan 30, 2013, at 7:20 PM, Nicolas Cellier wrote: > >> In st-80 these were protocols and the name make you think of it differently. > > nicolas normally in the book we use protocols and I normally picky about it. > I do not like categories even for classes :) > So I will check. > > Stef >
I thought it was due to Monticello, because both class category/method category must match to make a pakage... But browsing a Squeak 1.3 image, i see some Browser protocol classified 'message category list', so it must be a rather ancient naming... I have vague recollection of st-80 v2 using same object to categorize classes and methods, so maybe it was already named category there too... For my part, I still prefer to think in term of protocol, numbers have protocol for doing arithmetic, for comparing, for printing,... Nicolas >> 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 >> >> <Bildschirmfoto 2013-01-30 um 22.17.17.png> >> >> 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 >>> >> >> > >
