[Pharo-project] I hate 'as yet unclassified'
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' Stef
2013/1/29 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?
Recategorizing means assigning categories to methods, not classification, so "unclassified" is not the proper word. So for me "uncategorized" would be a good fit. Regards.
'CATEGORIZE ME' Because smalltalkers hate upper cased letters, so everyone will categorize them quickly ;) On 29 janv. 2013, at 16:57, Stéphane Ducasse wrote:
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.
+1 :) Ben On Jan 29, 2013, at 5:06 PM, wam <camille.teruel@gmail.com> wrote:
'CATEGORIZE ME' Because smalltalkers hate upper cased letters, so everyone will categorize them quickly ;)
On 29 janv. 2013, at 16:57, Stéphane Ducasse wrote:
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.
On Jan 29, 2013, at 1:06 PM, wam wrote:
'CATEGORIZE ME' Because smalltalkers hate upper cased letters, so everyone will categorize them quickly ;)
:) may be should add 'ASs****' I really hate hate hate all this easy sloppiness. Stef
On 29 janv. 2013, at 16:57, Stéphane Ducasse wrote:
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.
While on the topic, some of the category chooser dialogs are sorted so that the extensions are listed first - which I find annoying (in 1.4). In 2.0 can the standard categories be shown first ? Also, I still struggle to really be confident I am choosing the right categories. Perhaps down the track, a feature useful for newcomers might be a tooltip when hovering over items on the category list, or alternatively, hover showing a list of the ten most common methods appearing in that category. cheers -ben Stéphane Ducasse wrote:
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'
Stef
On Jan 29, 2013, at 2:03 PM, Ben Coman wrote:
While on the topic, some of the category chooser dialogs are sorted so that the extensions are listed first - which I find annoying (in 1.4). In 2.0 can the standard categories be shown first ?
Also, I still struggle to really be confident I am choosing the right categories. Perhaps down the track, a feature useful for newcomers might be a tooltip when hovering over items on the category list, or alternatively, hover showing a list of the ten most common methods appearing in that category.
could be really neat :)
cheers -ben
Stéphane Ducasse wrote:
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'
Stef
Code with "as yet unclassified" methods should be rejected by the monkey ! Ben On Jan 29, 2013, at 11:19 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 29, 2013, at 2:03 PM, Ben Coman wrote:
While on the topic, some of the category chooser dialogs are sorted so that the extensions are listed first - which I find annoying (in 1.4). In 2.0 can the standard categories be shown first ?
Also, I still struggle to really be confident I am choosing the right categories. Perhaps down the track, a feature useful for newcomers might be a tooltip when hovering over items on the category list, or alternatively, hover showing a list of the ten most common methods appearing in that category.
could be really neat :)
cheers -ben
Stéphane Ducasse wrote:
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'
Stef
Ok but in 3.0 We will kill that bad habit. We should investigate in an automatic categorizer. There was one I should have a look one of these days (since I do not know what to do :)). Stef
Code with "as yet unclassified" methods should be rejected by the monkey !
Ben
On Jan 29, 2013, at 11:19 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Jan 29, 2013, at 2:03 PM, Ben Coman wrote:
While on the topic, some of the category chooser dialogs are sorted so that the extensions are listed first - which I find annoying (in 1.4). In 2.0 can the standard categories be shown first ?
Also, I still struggle to really be confident I am choosing the right categories. Perhaps down the track, a feature useful for newcomers might be a tooltip when hovering over items on the category list, or alternatively, hover showing a list of the ten most common methods appearing in that category.
could be really neat :)
cheers -ben
Stéphane Ducasse wrote:
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'
Stef
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
2013/1/30 Norbert Hartl <norbert@hartl.name>:
(SNIP) 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.
I agree with this, I'd fine if the method browser doesn't have any category pane at all. Most of the times the selectors are self describing, and a short list of them. I only used the categories to search methods in classes like String, where you try to find some specific behavior (most of the time under the "printing" or "converting" category). Regards,
To be honest I have problems understanding why method categorization is so important.
It provides a look into the mind of the author.
Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :)
Ha! I remember when I used to voluntarily submit myself to lint's slavery. For a while I was putting in selectors to ignore or whatever the filtering capability it had -- until one day I said, "enough". Since then I mostly just check for "Bugs" -- let lint work for ME. Perhaps a better approach to help you relax would be to remove that particular Lint rule..? :) Ahh, freedom. :) Categories they are "integrated documentation" and, the fact that some methods remain 'as yet unclassified' IS meaningful -- it indicates that the class is either private or single-purpose. There are a lot of "code elements" in the system (classes, methods, categories, packages, etc.) and so sometimes, as you said, classes are simple enough that additional category elements are not needed. Categories are the domain of humans, not machines. They're for the writer to communicate to the readers. Auto-categorization does not increase the effectiveness of categories -- in fact I think it would dilute it.
What is the use? Declaring usage patterns?
Yes.
.. Declaring visibility?
Yes.
Use as method extensions marker?
Yes. 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.
Two ways to do that (at least in Pharo 1.4, not sure about 2.0). 1) With focus on the methods list, press Shift+Command+C. 2) Turn on System | Settings | Code browsing | Show annotation panes.
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.
+1. Because "as yet" implies it "will" or "needs" to be classified, which isn't always true.
I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code. Methods are classified using the following rules: 1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..) 2. getters and setters of instance variables 3. know protocols of super implementors 4. gather all implementors in the system and choose the most used protocol. I guess that will cover most stuff, of course known prefixes will have to be extended... On 2013-01-30, at 20:52, Chris Muller <asqueaker@gmail.com> wrote:
To be honest I have problems understanding why method categorization is so important.
It provides a look into the mind of the author.
Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :)
Ha! I remember when I used to voluntarily submit myself to lint's slavery. For a while I was putting in selectors to ignore or whatever the filtering capability it had -- until one day I said, "enough". Since then I mostly just check for "Bugs" -- let lint work for ME. Perhaps a better approach to help you relax would be to remove that particular Lint rule..? :) Ahh, freedom. :)
Categories they are "integrated documentation" and, the fact that some methods remain 'as yet unclassified' IS meaningful -- it indicates that the class is either private or single-purpose. There are a lot of "code elements" in the system (classes, methods, categories, packages, etc.) and so sometimes, as you said, classes are simple enough that additional category elements are not needed.
Categories are the domain of humans, not machines. They're for the writer to communicate to the readers. Auto-categorization does not increase the effectiveness of categories -- in fact I think it would dilute it.
What is the use? Declaring usage patterns?
Yes.
.. Declaring visibility?
Yes.
Use as method extensions marker?
Yes.
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.
Two ways to do that (at least in Pharo 1.4, not sure about 2.0).
1) With focus on the methods list, press Shift+Command+C. 2) Turn on System | Settings | Code browsing | Show annotation panes.
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.
+1. Because "as yet" implies it "will" or "needs" to be classified, which isn't always true.
On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code.
Methods are classified using the following rules:
1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..)
"testing" are typically reserved for methods that begin with the word "is". Methods beginning with "test" probably should be under "tests".
2. getters and setters of instance variables
Hmm. Sometimes "accessing" is not always the right category for these but I suppose it wouldn't hurt for it to start there most of the time.
3. know protocols of super implementors
I admit that is a good one.
4. gather all implementors in the system and choose the most used protocol.
You might consider to leave such methods exposed as uncategorized rather than to "hide" them in an incorrect categories.
I guess that will cover most stuff, of course known prefixes will have to be extended...
On 2013-01-30, at 21:53, Chris Muller <asqueaker@gmail.com> wrote:
On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code.
Methods are classified using the following rules:
1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..)
"testing" are typically reserved for methods that begin with the word "is". Methods beginning with "test" probably should be under "tests".
right :) I even added 'testing' for the 'is' prefix further down the code :P
2. getters and setters of instance variables
Hmm. Sometimes "accessing" is not always the right category for these but I suppose it wouldn't hurt for it to start there most of the time.
true, but as you say, it's the best guess we can do :)
3. know protocols of super implementors
I admit that is a good one.
4. gather all implementors in the system and choose the most used protocol.
You might consider to leave such methods exposed as uncategorized rather than to "hide" them in an incorrect categories.
maybe, but then again it's an auto categorizer, which will try to guess. currently methods are classified rather randomly...
On Wed, Jan 30, 2013 at 12:53 PM, Chris Muller <asqueaker@gmail.com> wrote:
On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code.
[snip]
3. know protocols of super implementors
I admit that is a good one.
I think this is execllent. I'd appreciate is a lot.
4. gather all implementors in the system and choose the most used protocol.
Not so much this one. If you limited the scope (say to siblings -
subclasses of it's superclass of the same level, ignoring Object as a superclass), I think this would also be excellent. Usually when I'm creating a set of related classes, I'll wind up making the categories (or protocols) similar - any help here is indeed help. -Chris
On 30 January 2013 21:40, Camillo Bruni <camillobruni@gmail.com> wrote:
I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code.
Methods are classified using the following rules:
1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..)
imo.. a test methods in test cases should be labeled 'tests' while 'testing' is for methods like isA... so, if class is subclass of TestCase, you should use 'tests' , and if not, then 'testing'
2. getters and setters of instance variables 3. know protocols of super implementors 4. gather all implementors in the system and choose the most used protocol.
I guess that will cover most stuff, of course known prefixes will have to be extended...
On 2013-01-30, at 20:52, Chris Muller <asqueaker@gmail.com> wrote:
To be honest I have problems understanding why method categorization is so important.
It provides a look into the mind of the author.
Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :)
Ha! I remember when I used to voluntarily submit myself to lint's slavery. For a while I was putting in selectors to ignore or whatever the filtering capability it had -- until one day I said, "enough". Since then I mostly just check for "Bugs" -- let lint work for ME. Perhaps a better approach to help you relax would be to remove that particular Lint rule..? :) Ahh, freedom. :)
Categories they are "integrated documentation" and, the fact that some methods remain 'as yet unclassified' IS meaningful -- it indicates that the class is either private or single-purpose. There are a lot of "code elements" in the system (classes, methods, categories, packages, etc.) and so sometimes, as you said, classes are simple enough that additional category elements are not needed.
Categories are the domain of humans, not machines. They're for the writer to communicate to the readers. Auto-categorization does not increase the effectiveness of categories -- in fact I think it would dilute it.
What is the use? Declaring usage patterns?
Yes.
.. Declaring visibility?
Yes.
Use as method extensions marker?
Yes.
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.
Two ways to do that (at least in Pharo 1.4, not sure about 2.0).
1) With focus on the methods list, press Shift+Command+C. 2) Turn on System | Settings | Code browsing | Show annotation panes.
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.
+1. Because "as yet" implies it "will" or "needs" to be classified, which isn't always true.
-- Best regards, Igor Stasenko.
Cool Camillo can I see the code? I was planning to look for the old autocategoriser. Stef
I just wrote a simple classifier which is going to be used in Nautilus. Basically it is an extensions of the existing code.
Methods are classified using the following rules:
1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..) could we have initialize and not initialize-release
2. getters and setters of instance variables 3. know protocols of super implementors 4. gather all implementors in the system and choose the most used protocol.
I guess that will cover most stuff, of course known prefixes will have to be extended...
On 2013-01-30, at 20:52, Chris Muller <asqueaker@gmail.com> wrote:
To be honest I have problems understanding why method categorization is so important.
It provides a look into the mind of the author.
Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :)
Ha! I remember when I used to voluntarily submit myself to lint's slavery. For a while I was putting in selectors to ignore or whatever the filtering capability it had -- until one day I said, "enough". Since then I mostly just check for "Bugs" -- let lint work for ME. Perhaps a better approach to help you relax would be to remove that particular Lint rule..? :) Ahh, freedom. :)
Categories they are "integrated documentation" and, the fact that some methods remain 'as yet unclassified' IS meaningful -- it indicates that the class is either private or single-purpose. There are a lot of "code elements" in the system (classes, methods, categories, packages, etc.) and so sometimes, as you said, classes are simple enough that additional category elements are not needed.
Categories are the domain of humans, not machines. They're for the writer to communicate to the readers. Auto-categorization does not increase the effectiveness of categories -- in fact I think it would dilute it.
What is the use? Declaring usage patterns?
Yes.
.. Declaring visibility?
Yes.
Use as method extensions marker?
Yes.
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.
Two ways to do that (at least in Pharo 1.4, not sure about 2.0).
1) With focus on the methods list, press Shift+Command+C. 2) Turn on System | Settings | Code browsing | Show annotation panes.
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.
+1. Because "as yet" implies it "will" or "needs" to be classified, which isn't always true.
I was just waiting for the google issue tracker to come back to life... https://code.google.com/p/pharo/issues/detail?id=7373 => Slice in Inbox the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common... On 2013-01-31, at 00:43, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Cool Camillo can I see the code? I was planning to look for the old autocategoriser.
Stef
Camillo Bruni wrote:
I was just waiting for the google issue tracker to come back to life...
https://code.google.com/p/pharo/issues/detail?id=7373
=> Slice in Inbox
the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common...
Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.
On 2013-01-31, at 03:53, Ben Coman <btc@openInWorld.com> wrote:
Camillo Bruni wrote:
I was just waiting for the google issue tracker to come back to life...
https://code.google.com/p/pharo/issues/detail?id=7373
=> Slice in Inbox
the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common...
Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.
the categorization will happen only upon user interaction. hence I think such a control is not needed directly. Feel free to extend the current classifier to support it, the code is fairly simple..
Auto categorization in the old browser: " Categorize all uncategorized " had simple rules especially overridden methods / known methods in their known categories.. That would help greatly for most developers, more so the beginners to get a good feel of recommended categorization. But can auto categorization cause wrong labeling may need to weighed, better to leave it uncategorized in that case. **************** PS: At work on a VAGE code, I was pointing to the exact same issue of missing categorization over last many years..!.. The lack of categorization limits comprehension of the codebase... especially of code built over 20 yrs. On Thursday, January 31, 2013, Camillo Bruni wrote:
On 2013-01-31, at 03:53, Ben Coman <btc@openInWorld.com> wrote:
Camillo Bruni wrote:
I was just waiting for the google issue tracker to come back to life...
https://code.google.com/p/pharo/issues/detail?id=7373
=> Slice in Inbox
the major problem I have now, is that wrong categorizations might
easily spread :P, the sepll-fleu and the space - vi rus, are very common...
Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.
the categorization will happen only upon user interaction. hence I think such a control is not needed directly. Feel free to extend the current classifier to support it, the code is fairly simple..
First, these are not categories. categories are for classes. These are protocols. 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. 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 <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
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 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
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 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
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
On 30 January 2013 22:20, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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 <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
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
2013/1/30 Frank Shearar <frank.shearar@gmail.com>
On 30 January 2013 22:20, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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 <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
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
Ah, here is a good link, http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html Let's read what those people naming things had in mind. Nicolas 2013/1/30 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>
2013/1/30 Frank Shearar <frank.shearar@gmail.com>
On 30 January 2013 22:20, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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 <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
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
On 30 January 2013 22:36, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
2013/1/30 Frank Shearar <frank.shearar@gmail.com>
On 30 January 2013 22:20, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> 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 <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
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
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
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
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
On 30 January 2013 21:03, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> 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 <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
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 <frank.shearar@gmail.com>:
On 30 January 2013 21:03, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> 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 <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
First, these are not categories. categories are for classes. These are protocols.
Yes :)
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.
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.
me too :)
To be honest I have problems understanding why method categorization is so important.
Because I do not like to live in an environment where there are papers on the floor. Did you read the pragmatic programmer book? I dislike these guys personally but the first book is excellent. "No broken window" Why do we remove deadcode? why do we comment classes? Stef
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
participants (14)
-
Ben Coman -
Benjamin -
Camille Teruel -
Camillo Bruni -
Chris Cunningham -
Chris Muller -
Esteban A. Maringolo -
Frank Shearar -
Igor Stasenko -
Nicolas Cellier -
Norbert Hartl -
S Krish -
Stéphane Ducasse -
wam