Of course, it's documentation only. The main value is when a general service is spreaded across class library Also 'testing' and 'accessing' would be questionnable from this POV. Querying and changing state are very wide band protocols ;)
The classification is also somewhat arbitrary, but for stream, I could expect some rather specialized 'reading' and 'writing' protocols. Let's say protocol classification was designed fuzzy enough to serve classification without too much fragmentation... (lower grain atoms are messages/methods) Nicolas 2013/1/30 Frank Shearar <[email protected]>: > On 30 January 2013 21:03, Nicolas Cellier > <[email protected]> wrote: >> First, these are not categories. categories are for classes. >> These are protocols. >> >> A protocol is like an interface, > > Yes, only no. Think of the messages that make something like a Stream: > you have accessing things (#next, ...), you have testing things > (#isEnd), you have mutating things (#nextPut:, ...). My point is that > the set of messages that make something like a Stream are spread > across several of the things we call "protocols". The Browser just > calls them "message categories" (as opposed to "system categories"). > > frank > >> 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. >> >> 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. >> >> 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 >> >
