January 2013 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Extent a Athens surface?

by Igor Stasenko

On 30 January 2013 18:14, MartinW <wm(a)fastmail.fm> wrote: > Igor Stasenko wrote >>>> I wanted to ask if it's possible to extent an Athens surface. If it >>>> can't be done, because as far as I understand this can't be done in >>>> Cairo, is it possible to simulate it at least? Is it possible to stop >>>> #drawDuring: and build another surface, maybe? >> how large? >> is >> >> AthensCairoSurface extent: 2000@2000 >> >> not works? > > I think it is about resizing an existing Morph that is drawn with Athens > Surface? I had problems with it and had the same question. But it works well > with something like: > > SomeSubclassOfMorph>>extent: aPoint > |newExtent| > newExtent := aPoint rounded. > (bounds extent closeTo: newExtent) ifTrue: [^ self]. > self changed. > bounds := (bounds topLeft extent: newExtent). > surface := AthensCairoSurface extent: newExtent. > self layoutChanged. > self changed. > > Now Boids fly in a resizable sky :) > yes. this is the way. you cannot resize existing surface, but create a new one instead. > > > -- > View this message in context: http://forum.world.st/Extent-a-Athens-surface-tp4665978p4666666.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Jan. 30, 2013

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

by Camillo Bruni

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(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. >

Jan. 30, 2013

Re: [Pharo-project] OrderedIdentityDictionary in a more general package

by Frank Shearar

On 30 January 2013 19:44, Torsten Bergmann <astares(a)gmx.de> wrote: > The class "OrderedIdentityDictionary" is currently defined in package "Spec-Core". > > Since it is useful also in other scenarios and I do not want a dependency > on spec: wouldnt it make sense to move it to a more common "Collections-..." > package. > > Since there is already "Collections-Unordered" I would suggest to put it > into "Collections-Ordered". > Mmmhh ... but then class OrderedCollection would have to move from "Collections-Sequenceable" > to "Collections-Ordered" as well (at least from the name). > > Any comments on that... > > Thx > T. If something is ordered, surely it's sequenceable? Why not put it in Collections-Sequenceable? frank

Jan. 30, 2013

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

by Chris Muller

> 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.

Jan. 30, 2013

[Pharo-project] OrderedIdentityDictionary in a more general package

by Torsten Bergmann

The class "OrderedIdentityDictionary" is currently defined in package "Spec-Core". Since it is useful also in other scenarios and I do not want a dependency on spec: wouldnt it make sense to move it to a more common "Collections-..." package. Since there is already "Collections-Unordered" I would suggest to put it into "Collections-Ordered". Mmmhh ... but then class OrderedCollection would have to move from "Collections-Sequenceable" to "Collections-Ordered" as well (at least from the name). Any comments on that... Thx T.

Jan. 30, 2013

[Pharo-project] help needed

by Usman Bhatti

I am trying to look into this issue in Glamour related to morphs: http://code.google.com/p/pharo/issues/detail?id=7345 The problem is that, in Glamour, one can choose to display first few items instead of the all and then the user can choose to display more. When the selection is set to the items not shown, there is a DNU in PaginatedMorphTreeMorph. Digging this problem, I have encountered this piece of code for which I would require the help of someone knowing Morph. Is someone knowledgable about this piece of code? Here you can find an image with the script to explore the problem: https://dl.dropbox.com/u/11804892/glamour-treemorphs.zip MorphTreeMorph >> update: update: aSymbol aSymbol == #selection ifTrue: [^ self listManager updateSelectionFromModel]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == #selectItems and: [aSymbol second isCollection]]]) ifTrue: [^ self selectedItems: aSymbol second]. aSymbol == self nodeListSelector ifTrue: [^ self updateList]. aSymbol == #selectAll ifTrue: [^ self listManager selectAll]. aSymbol == #deselectAll ifTrue: [^ self listManager deselectAll]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #openPath]]]) "allow directed path opening where multiple trees exist" ifTrue: [^(self allNodeMorphs at: 1 ifAbsent: [^self]) openPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #openItemPath]]]) "allow directed path opening where multiple trees exist" ifTrue: [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) openItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #expandAllFromNode:]]]) ifTrue: [^ self expandAllFromNode: aSymbol third]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == self nodeListSelector and: [ aSymbol second == #closeItemPath]]]) "allow directed path closing where multiple trees exist" ifTrue: [^ (self allNodeMorphs at: 1 ifAbsent: [^self]) closeItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) ifTrue: [^(self allNodeMorphs at: 1 ifAbsent: [^self]) openPath: aSymbol allButFirst]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector and: [ aSymbol second == #expandRoots]]]) ifTrue: [^self expandRoots]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = self nodeListSelector]]) ifTrue: [aSymbol second = #expandAll ifTrue: [^ self expandAll]. aSymbol second = #collapseAll ifTrue: [^ self collapseAll]]

Jan. 30, 2013