2013/1/31 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 <norbert@hartl.name>
Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
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 <norbert@hartl.name>:
Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse <stephane.ducasse@inria.fr>:
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