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