- Pharo-dev - lists.pharo.org

Re: [Pharo-project] I hate 'as yet unclassified'

by Nicolas Cellier

2013/1/30 Frank Shearar <frank.shearar(a)gmail.com> > On 30 January 2013 22:20, Nicolas Cellier < > nicolas.cellier.aka.nice(a)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(a)hartl.name> >> >>> >>> Am 30.01.2013 um 22:03 schrieb Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)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(a)hartl.name>: >>> >>> >>> Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse < >>> stephane.ducasse(a)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 >>> >>> >>> >>> >> >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Nicolas Cellier

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(a)gmail.com>: > On 30 January 2013 21:03, Nicolas Cellier > <nicolas.cellier.aka.nice(a)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(a)hartl.name>: >>> >>> Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse <stephane.ducasse(a)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 >> >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Frank Shearar

On 30 January 2013 22:20, Nicolas Cellier < nicolas.cellier.aka.nice(a)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(a)hartl.name> > >> >> Am 30.01.2013 um 22:03 schrieb Nicolas Cellier < >> nicolas.cellier.aka.nice(a)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(a)hartl.name>: >> >> >> Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse < >> stephane.ducasse(a)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 >> >> >> >> >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Nicolas Cellier

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(a)hartl.name> > > Am 30.01.2013 um 22:03 schrieb Nicolas Cellier < > nicolas.cellier.aka.nice(a)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(a)hartl.name>: > > > Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse <stephane.ducasse(a)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 > > > >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Frank Shearar

On 30 January 2013 21:03, Nicolas Cellier <nicolas.cellier.aka.nice(a)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(a)hartl.name>: >> >> Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse <stephane.ducasse(a)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 >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Norbert Hartl

Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)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(a)hartl.name>: >> >> Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse <stephane.ducasse(a)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 >

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Camillo Bruni

On 2013-01-30, at 21:53, Chris Muller <asqueaker(a)gmail.com> wrote: > On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <camillobruni(a)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...

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Nicolas Cellier

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(a)hartl.name>: > > Am 29.01.2013 um 16:57 schrieb StÃ©phane Ducasse <stephane.ducasse(a)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

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Igor Stasenko

On 30 January 2013 21:40, Camillo Bruni <camillobruni(a)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(a)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.

Jan. 30, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by Chris Muller

On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <camillobruni(a)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...

Jan. 30, 2013