On 30 January 2013 22:36, Nicolas Cellier < [email protected]> wrote:
> > 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 ;) > My understanding of "protocol" means "how do I talk to this thing?" while yours is "these sets of messages for this object do similar things". 'testing' giving you the _subset_ of an object's understood messages that return Boolean, for instance. "What's the testing protocol of this object?" sounds wrong to my ears. Now you could say "the things that make something Streamlike" (what I'd call a protocol) "are the things that Stream implements", and that's really what I'd like to aim for. <<foo supports: Stream>> would return true if foo supported the set of messages that Stream supported - if it understood the _protocol_ of Stream. Ah, and from that link we see "Every object in Smalltalk, even a lowly integer, has a set of messages, a protocol, that defines the explicit communication to which that object can respond." (I may well be cherrypicking; I haven't read the paper properly yet.) frank > > 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>>
