2013/1/30 Frank Shearar <[email protected]> > On 30 January 2013 22:20, Nicolas Cellier < > [email protected]> wrote: > >> 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 >> > > Sure. I also remember people talking about "the protocol of Foo", meaning > the set of messages that Foo understood. That's how the Objective-C and > Clojure people understand the term, for what it's worth. > > Sometimes the those who came before named things poorly... :) > > I don't know what you think was named poorly... I just wonder, in term of communicating by sending messages, what is the best name for defining the set of messages an object can understand? Category or protocol ;)
Nicolas frank > > > >> 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>>
