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

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

by StÃ©phane Ducasse

I'm not blaming, blaming is not interesting. I want to fix them. - automatically as much as possible - with social pressure ie CATEGORISE ME PLEASE > But blaming people who contribute (a lot) might not be the best strategy. Often the author is the one who last changed a method, the missing categorisation was probably already there. Also, creating methods from certain tools makes then automatically uncategorisedâ¦

Jan. 30, 2013

[Pharo-project] Cross-classified methods

by Stephan Eggermont

When I map the list of unclassified methods in Squeak 4.3 on class name & method name in Pharo 20498, I find the following classifications. First in Squeak for Pharo HttpUrlTest testHttps testing UUIDTest testComparison testing TextAction analyze: testing TextAction dominatedByCmd0 testing TextAction emphasizeScanner: styling TextAction info accessing TextAction validate: testing TextAlignment = testing TextAlignment alignment accessing TextAlignment alignment: accessing TextAlignment dominates: testing TextAlignment emphasizeScanner: utils TextAlignment hash testing TextAlignment writeScanOn: utils TextAttribute anchoredMorph accessing TextAttribute dominatedByCmd0 testing TextAttribute dominates: accessing TextAttribute emphasisCode styling TextAttribute emphasizeScanner: styling TextAttribute forFontInStyle:do: styling TextAttribute mayBeExtended testing TextAttribute oldEmphasisCode: styling TextAttribute reset accessing TextAttribute set accessing TextDoIt analyze: testing TextDoIt evalString: accessing TextDoIt info accessing TextDoIt writeScanOn: styling TextEmphasis = comparing TextEmphasis dominatedByCmd0 testing TextEmphasis dominates: accessing TextEmphasis emphasisCode styling TextEmphasis emphasisCode: accessing TextEmphasis emphasizeScanner: styling TextEmphasis hash comparing TextEmphasis printOn: printing TextEmphasis set accessing TextEmphasis turnOff accessing TextEmphasis writeScanOn: styling TextLink analyze: testing TextLink analyze:with: testing TextLink classAndMethod: accessing TextLink info accessing TextLink validate: testing TextLink writeScanOn: styling TextPrintIt writeScanOn: styling TextURL analyze: testing TextURL info accessing TextURL url: accessing TextURL writeScanOn: styling LayoutFrameTest testInset tests LayoutFrameTest testLeftTopAligned tests LayoutFrameTest testRightBottomQuadrant tests LayoutFrameTest testSpaceFill tests FileStreamTest testCachingNextChunkPut testing FileStreamTest testDetectFileDo testing FileStreamTest testFileTruncation testing FileStreamTest testNextChunkOutOfBounds testing FileStreamTest testNextLine testing HashAndEqualsTestCase setUp running HashAndEqualsTestCase testEquality testing HashAndEqualsTestCase testHash testing MCClassDefinitionTest classAComment private MCClassDefinitionTest creationMessage private MCClassDefinitionTest tearDown running MCClassDefinitionTest testCannotLoad tests MCClassDefinitionTest testComparison tests MCClassDefinitionTest testCreation tests MCClassDefinitionTest testDefinitionString tests MCClassDefinitionTest testEquals tests MCClassDefinitionTest testEqualsSensitivity tests MCClassDefinitionTest testKindOfSubclass tests MCClassDefinitionTest testLoadAndUnload tests MCDictionaryRepositoryTest addVersion: actions MCDictionaryRepositoryTest deleteNode: utility MCDictionaryRepositoryTest dictionary utility MCDictionaryRepositoryTest setUp running MCDirectoryRepositoryTest addVersion: actions MCDirectoryRepositoryTest directory accessing MCDirectoryRepositoryTest setUp running MCDirectoryRepositoryTest tearDown running MCOrganizationTest testReordering tests MCOrganizationTest testReorderingWithNoCategoriesInVersion tests MCOrganizationTest testReorderingWithRemovals tests MCPatchTest setUp running MCPatchTest tearDown running MCPatchTest testPatchContents tests MCSnapshotResource definitions accessing MCSnapshotResource setUp running MCSnapshotResource snapshot accessing MCStReaderTest commentWithStyle util MCStReaderTest commentWithoutStyle util MCStReaderTest methodWithStyle util MCStReaderTest testCommentWithStyle tests MCStReaderTest testCommentWithoutStyle tests MCStReaderTest testMethodWithStyle tests MethodChangeRecord printOn: printing MCAddition inverse accessing MCAddition isClassPatch testing MCChangeSelectionRequest defaultAction *MonticelloGUI MCChangeSelector widgetSpecs as yet unclassified MCClassInstanceVariableDefinition isClassInstanceVariable testing MCClassTraitDefinition load installing MCClassTraitParser addDefinitionsTo: actions MCClassVariableDefinition isClassVariable testing MCClassVariableDefinition isOrderDependend testing MCDictionaryRepository morphicOpen: *MonticelloGUI MCDoItParser addDefinitionsTo: actions MCDoItParser source accessing MCDoItParser source: accessing MCHttpRepository asCreationTemplate converting MCHttpRepository location: accessing MCHttpRepository locationWithTrailingSlash actions MCHttpRepository parseFileNamesFromStream: actions MCHttpRepository password actions MCHttpRepository password: accessing MCHttpRepository urlForFileNamed: actions MCHttpRepository user accessing MCHttpRepository user: accessing MCHttpRepository userAndPasswordFromSettingsDo: actions MCHttpRepository versionReaderForFileNamed: actions MCHttpRepository versionReaderForFileNamed:do: actions MCInstanceVariableDefinition isInstanceVariable testing MCMczReader loadDefinitions loading MCMczReader loadDependencies loading MCMczReader loadPackage loading MCMczReader loadVersionInfo loading MCMergeBrowser buttonSpecs morphic ui MCMergeBrowser canMerge actions MCMergeBrowser cancel actions MCMergeBrowser chooseAllNewerConflicts *Polymorph-Tools-Diff MCMergeBrowser chooseAllOlderConflicts *Polymorph-Tools-Diff MCMergeBrowser chooseAllUnchosenLocal *Polymorph-Tools-Diff MCMergeBrowser chooseAllUnchosenRemote *Polymorph-Tools-Diff MCMergeBrowser chooseLocal *Polymorph-Tools-Diff MCMergeBrowser chooseRemote *Polymorph-Tools-Diff MCMergeBrowser clearChoice actions MCMergeBrowser conflictSelectionDo: actions MCMergeBrowser defaultLabel morphic ui MCMergeBrowser getConflictMenu: actions MCMergeBrowser getMenu: morphic ui MCMergeBrowser getOperationMenu: actions MCMergeBrowser innerButtonRow actions MCMergeBrowser items accessing MCMergeBrowser merge actions MCMergeBrowser merger: actions MCMergeBrowser selectionIsConflicted actions MCMergeBrowser widgetSpecs morphic ui MCMergeResolutionRequest defaultAction *Polymorph-Tools-Diff MCMerger addConflictWithOperation: operations MCMerger applyTo: operations MCMerger conflicts accessing MCMerger isMerged testing MCMerger load operations MCMerger loadWithNameLike: operations MCMerger mergedSnapshot accessing MCMerger operations accessing MCMerger provisions accessing MCModification inverse accessing MCModification isClassPatch testing MCModification printAnnotations:on: accessing MCPatchBrowser annotations accessing MCPatchBrowser changeSetNameForInstall actions MCRemoval inverse accessing MCRemoval isClassPatch testing MCSaveVersionDialog accept morphic ui MCSaveVersionDialog buttonSpecs morphic ui MCSaveVersionDialog cancel morphic ui MCSaveVersionDialog defaultExtent morphic ui MCSaveVersionDialog defaultLabel morphic ui MCSaveVersionDialog logMessage accessing MCSaveVersionDialog logMessage: accessing MCSaveVersionDialog versionName accessing MCSaveVersionDialog versionName: accessing MCSaveVersionDialog widgetSpecs morphic ui MCScanner next actions MCScanner nextArray actions MCScanner nextString actions MCScanner nextSymbol actions MCScanner stream: accessing MCScriptParser addDefinitionsTo: actions MCSystemCategoryParser addDefinitionsTo: actions MCSystemCategoryParser category accessing MCThreeWayMerger addBaseSnapshot: operations MCThreeWayMerger addDefinition: operations MCThreeWayMerger addOperation: operations MCThreeWayMerger applyPatch: operations MCThreeWayMerger baseSnapshot operations MCThreeWayMerger initialize initialize-release MCThreeWayMerger modificationConflictForDefinition: operations MCThreeWayMerger modifyDefinition:to: operations MCThreeWayMerger operations accessing MCThreeWayMerger provisions accessing MCThreeWayMerger redundantAdds operations MCThreeWayMerger removalForDefinition: operations MCThreeWayMerger removeDefinition: operations MCThreeWayMerger removeOperation: operations MCTraitParser addDefinitionsTo: actions MCVersionInfoWriter isWritten: testing MCVersionInfoWriter writeVersionInfo: serialization MCVersionInfoWriter written accessing MCVersionInfoWriter wrote: serialization MCVersionNameAndMessageRequest defaultAction *MonticelloGUI MCWriteOnlyRepository morphicOpen: *MonticelloGUI MethodAddition compile compilation MethodAddition compile:classified:withStamp:notifying:logSource:inClass: compilation MethodAddition createCompiledMethod operations MethodAddition installMethod operations MethodAddition notifyObservers notifying MethodAddition writeSourceToLog operations OutOfMemory defaultAction handling OutOfMemory isResumable testing LongTestCaseTest setUp setup LongTestCaseTest tearDown setup SUnitExtensionsTest testExceptionWithMatchingString tests SUnitExtensionsTest testExceptionWithoutMatchingString tests SUnitExtensionsTest testNoExceptionWithMatchingString tests SUnitExtensionsTest testNoExceptionWithNoMatchingString tests ClassCommentReader scanFrom: fileIn/Out ClassCommentReader scanFromNoCompile: fileIn/Out StrikeFontSet ascent accessing StrikeFontSet baseKern accessing StrikeFontSet derivativeFonts accessing StrikeFontSet descent accessing StrikeFontSet familyName accessing StrikeFontSet height accessing StrikeFontSet installOn:foregroundColor:backgroundColor: displaying StrikeFontSet lineGrid accessing StrikeFontSet name testing StrikeFontSet pointSize accessing StrikeFontSet printOn: printing StrikeFontSet widthOfString: measuring StrikeFontSet xTable accessing AColorSelectorMorph defaultFillStyle protocol AbstractResizerMorph dotColor actions AbstractResizerMorph handleColor actions AbstractResizerMorph handlesMouseDown: event handling AbstractResizerMorph handlesMouseOver: *Polymorph-Widgets AbstractResizerMorph initialize initialize AbstractResizerMorph isCursorOverHandle testing AbstractResizerMorph mouseDown: event handling AbstractResizerMorph mouseEnter: *Polymorph-Widgets AbstractResizerMorph mouseLeave: *Polymorph-Widgets AbstractResizerMorph resizeCursor actions AbstractResizerMorph setDefaultColors actions AbstractResizerMorph setInverseColors actions BracketSliderMorph defaultFillStyle protocol BracketSliderMorph extent: geometry BracketSliderMorph fillStyleToUse accessing BracketSliderMorph initialize initialization BracketSliderMorph initializeSlider initialization BracketSliderMorph layoutBounds: layout BracketSliderMorph roomToMove geometry BracketSliderMorph sliderColor: access BracketSliderMorph sliderShadowColor access BracketSliderMorph sliderThickness geometry BracketSliderMorph updateFillStyle protocol CornerGripMorph initialize initialize CornerGripMorph mouseMove: event CornerGripMorph target: accessing HColorSelectorMorph color: accessing HColorSelectorMorph defaultFillStyle protocol HaloSpec addHandleSelector actions HaloSpec color accessing HaloSpec horizontalPlacement accessing HaloSpec horizontalPlacement:verticalPlacement:color:iconSymbol:addHandleSelector: setter HaloSpec iconSymbol accessing HaloSpec verticalPlacement accessing IconicButton labelFromString: accessing IconicButton labelGraphic: *Polymorph-Widgets-override IconicButton shedSelvedge accessing MulticolumnLazyListMorph getListItem: list access MulticolumnLazyListMorph listChanged row management PluggableListMorph listMorph accessing PluggableListMorph listMorphClass initialization PluggableSliderMorph adoptPaneColor: accessing PluggableSliderMorph borderStyleToUse protocol PluggableSliderMorph defaultColor initialization PluggableSliderMorph disable protocol PluggableSliderMorph enable protocol PluggableSliderMorph fillStyleToUse accessing PluggableSliderMorph getValueSelector accessing PluggableSliderMorph getValueSelector: accessing PluggableSliderMorph handlesMouseDown: event handling PluggableSliderMorph initialize initialization PluggableSliderMorph initializeSlider initialization PluggableSliderMorph layoutBounds: layout PluggableSliderMorph minHeight layout PluggableSliderMorph mouseDown: event handling PluggableSliderMorph mouseDownInSlider: other events PluggableSliderMorph on:getValue:setValue: instance creation PluggableSliderMorph scaledValue accessing PluggableSliderMorph scaledValue: accessing PluggableSliderMorph scrollAbsolute: scrolling PluggableSliderMorph scrollPoint: event handling PluggableSliderMorph setValue: model access PluggableSliderMorph setValueSelector accessing PluggableSliderMorph setValueSelector: accessing PluggableSliderMorph sliderColor: access PluggableSliderMorph update: protocol PluggableSliderMorph updateEnabled protocol PluggableSliderMorph updateValue protocol Bitmap asByteArray conversion ProgressInitiationException defaultAction action ProgressInitiationException display:at:from:to:during: initialize-release ProgressInitiationException sendNotificationsTo: action SymbolTest testNumArgs2 tests Then for Pharo in Squeak MCRepositoryGroup addRepository: add / remove MCRepositoryGroup includes: testing MCRepositoryGroup includesVersionNamed: testing MCRepositoryGroup initialize initialize-release MCRepositoryGroup removeRepository: add / remove MCRepositoryGroup repositories accessing MCRepositoryGroup repositoriesDo: accessing MCRepositoryGroup versionWithInfo: accessing MCRepositoryGroup versionWithInfo:ifNone: accessing RWBinaryOrTextStream asBinaryOrTextStream converting RWBinaryOrTextStream ascii accessing RWBinaryOrTextStream binary accessing RWBinaryOrTextStream contents accessing RWBinaryOrTextStream isBinary testing RWBinaryOrTextStream next accessing RWBinaryOrTextStream next: accessing RWBinaryOrTextStream next:into:startingAt: accessing RWBinaryOrTextStream nextPut: accessing RWBinaryOrTextStream readInto:startingAt:count: accessing RWBinaryOrTextStream reset positioning RWBinaryOrTextStream text accessing RWBinaryOrTextStream upToEnd accessing StrikeFontFixer initialize initialize-release FloatTest testFractionAsFloatWithUnderflow testing - conversion PasteUpMorph mouseDown: event handling RenderBugz long utility RenderBugz shouldntTakeLong: utility RenderBugz testForward tests RenderBugz testHeading tests RenderBugz testSetForward tests RenderBugz testTestTime tests ListItemWrapper highlightingColor accessing PasteUpMorph mouseDown: event handling TextMorph keyboardFocusChange: event handling TextMorph yellowButtonActivity: event handling OrderedCollectionTest testStreamContents testStreaming FloatTest testFractionAsFloatWithUnderflow testing - conversion RWBinaryOrTextStream asBinaryOrTextStream converting RWBinaryOrTextStream ascii accessing RWBinaryOrTextStream binary accessing RWBinaryOrTextStream contents accessing RWBinaryOrTextStream isBinary testing RWBinaryOrTextStream next accessing RWBinaryOrTextStream next: accessing RWBinaryOrTextStream next:into:startingAt: accessing RWBinaryOrTextStream nextPut: accessing RWBinaryOrTextStream readInto:startingAt:count: accessing RWBinaryOrTextStream reset positioning RWBinaryOrTextStream text accessing RWBinaryOrTextStream upToEnd accessing ParserNotification openMenuIn: handling ParserNotification setName: private RenderBugz long utility RenderBugz shouldntTakeLong: utility RenderBugz testForward tests RenderBugz testHeading tests RenderBugz testSetForward tests RenderBugz testTestTime tests MCDirectoryRepository description accessing MCDirectoryRepository directory accessing MCDirectoryRepository directory: accessing MCDirectoryRepository initialize accessing MCDirectoryRepository isValid accessing MCDirectoryRepository readStreamForFileNamed:do: accessing MCDirectoryRepository writeStreamForFileNamed:replace:do: accessing MCFileBasedRepository allFileNames private-files MCFileBasedRepository allFileNamesForVersionNamed: private-files MCFileBasedRepository allFileNamesOrCache private-files MCFileBasedRepository allVersionNames private-files MCFileBasedRepository basicStoreVersion: overriding MCFileBasedRepository cache private MCFileBasedRepository cacheAllFileNamesDuring: private MCFileBasedRepository cachedFileNames private MCFileBasedRepository canReadFileNamed: private-files MCFileBasedRepository closestAncestorVersionFor:ifNone: overriding MCFileBasedRepository filterFileNames:forVersionNamed: private-files MCFileBasedRepository flushCache private MCFileBasedRepository includesVersionNamed: versions MCFileBasedRepository loadVersionFromFileNamed: private-files MCFileBasedRepository loadVersionInfoFromFileNamed: private-files MCFileBasedRepository maxCacheSize private MCFileBasedRepository notifyList overriding MCFileBasedRepository readableFileNames private-files MCFileBasedRepository resizeCache: private MCFileBasedRepository versionInfoFromFileNamed: private-files MCFileBasedRepository versionReaderForFileNamed:do: private-files MCFileBasedRepository versionWithInfo:ifAbsent: versions MCFileBasedRepository writeStreamForFileNamed:do: private-files MCRepository = testing MCRepository alwaysStoreDiffs accessing MCRepository asCreationTemplate accessing MCRepository basicStoreVersion: private MCRepository closestAncestorVersionFor:ifNone: accessing MCRepository creationTemplate accessing MCRepository creationTemplate: accessing MCRepository description accessing MCRepository doAlwaysStoreDiffs accessing MCRepository doNotAlwaysStoreDiffs accessing MCRepository hash testing MCRepository notificationForVersion: accessing MCRepository notifyList accessing MCRepository possiblyNewerVersionsOfAnyOf: versions MCRepository prepareVersionForStorage: accessing MCRepository printOn: printing MCRepository sendNotificationsForVersion: accessing MCRepository storeVersion: accessing StrikeFontFixer initialize initialize-release MCOrganizationDefinition accept: actions MCOrganizationDefinition categories accessing MCOrganizationDefinition categories: accessing MCOrganizationDefinition commonPrefix accessing MCOrganizationDefinition description accessing MCOrganizationDefinition isOrganizationDefinition testing MCOrganizationDefinition postloadOver: actions MCOrganizationDefinition reorderCategories:original: actions MCOrganizationDefinition sortKey accessing MCOrganizationDefinition source accessing MCOrganizationDefinition summary accessing OrderedCollectionTest testStreamContents testStreaming ParserNotification openMenuIn: handling ParserNotification setName: private TextMorph keyboardFocusChange: event handling TextMorph yellowButtonActivity: event handling ColorPresenterMorph initialize initializing ColorPresenterMorph newContentMorph initializing ColorPresenterMorph newHatchMorph initializing ColorPresenterMorph newLabelMorph initializing ColorPresenterMorph on:color: initializing ColorPresenterMorph setColor: initializing ColorPresenterMorph update: initializing ColorPresenterMorph updateColor initializing ListItemWrapper highlightingColor accessing MCRepositoryInspector hasVersion morphic ui MCRepositoryInspector load actions MCRepositoryInspector refresh actions MCRepositoryInspector setRepository:workingCopy: initialize-release MCRepositoryInspector version morphic ui MCTool show morphic ui MCTool showLabelled: morphic ui ColorPresenterMorph initialize initializing ColorPresenterMorph newContentMorph initializing ColorPresenterMorph newHatchMorph initializing ColorPresenterMorph newLabelMorph initializing ColorPresenterMorph on:color: initializing ColorPresenterMorph setColor: initializing ColorPresenterMorph update: initializing ColorPresenterMorph updateColor initializing MCDirectoryRepository description accessing MCDirectoryRepository directory accessing MCDirectoryRepository directory: accessing MCDirectoryRepository initialize accessing MCDirectoryRepository isValid accessing MCDirectoryRepository readStreamForFileNamed:do: accessing MCDirectoryRepository writeStreamForFileNamed:replace:do: accessing MCFileBasedRepository allFileNames private-files MCFileBasedRepository allFileNamesForVersionNamed: private-files MCFileBasedRepository allFileNamesOrCache private-files MCFileBasedRepository allVersionNames private-files MCFileBasedRepository basicStoreVersion: overriding MCFileBasedRepository cache private MCFileBasedRepository cacheAllFileNamesDuring: private MCFileBasedRepository cachedFileNames private MCFileBasedRepository canReadFileNamed: private-files MCFileBasedRepository closestAncestorVersionFor:ifNone: overriding MCFileBasedRepository filterFileNames:forVersionNamed: private-files MCFileBasedRepository flushCache private MCFileBasedRepository includesVersionNamed: versions MCFileBasedRepository loadVersionFromFileNamed: private-files MCFileBasedRepository loadVersionInfoFromFileNamed: private-files MCFileBasedRepository maxCacheSize private MCFileBasedRepository notifyList overriding MCFileBasedRepository readableFileNames private-files MCFileBasedRepository resizeCache: private MCFileBasedRepository versionInfoFromFileNamed: private-files MCFileBasedRepository versionReaderForFileNamed:do: private-files MCFileBasedRepository versionWithInfo:ifAbsent: versions MCFileBasedRepository writeStreamForFileNamed:do: private-files MCOrganizationDefinition accept: actions MCOrganizationDefinition categories accessing MCOrganizationDefinition categories: accessing MCOrganizationDefinition commonPrefix accessing MCOrganizationDefinition description accessing MCOrganizationDefinition isOrganizationDefinition testing MCOrganizationDefinition postloadOver: actions MCOrganizationDefinition reorderCategories:original: actions MCOrganizationDefinition sortKey accessing MCOrganizationDefinition source accessing MCOrganizationDefinition summary accessing MCRepository = testing MCRepository alwaysStoreDiffs accessing MCRepository asCreationTemplate accessing MCRepository basicStoreVersion: private MCRepository closestAncestorVersionFor:ifNone: accessing MCRepository creationTemplate accessing MCRepository creationTemplate: accessing MCRepository description accessing MCRepository doAlwaysStoreDiffs accessing MCRepository doNotAlwaysStoreDiffs accessing MCRepository hash testing MCRepository notificationForVersion: accessing MCRepository notifyList accessing MCRepository possiblyNewerVersionsOfAnyOf: versions MCRepository prepareVersionForStorage: accessing MCRepository printOn: printing MCRepository sendNotificationsForVersion: accessing MCRepository storeVersion: accessing MCRepositoryGroup addRepository: add / remove MCRepositoryGroup includes: testing MCRepositoryGroup includesVersionNamed: testing MCRepositoryGroup initialize initialize-release MCRepositoryGroup removeRepository: add / remove MCRepositoryGroup repositories accessing MCRepositoryGroup repositoriesDo: accessing MCRepositoryGroup versionWithInfo: accessing MCRepositoryGroup versionWithInfo:ifNone: accessing

Jan. 30, 2013

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

by StÃ©phane Ducasse

such queries do not mean much because people change code. Anyway. I spent time on categorizing methods when I do not have my brain on to do something useful. Stef > In Pharo 20498, sorted by author in the method timestamp: > > gvc 1550 > AlainPlantec 320 > 216 > GaryChambers 215 > CamilloBruni 163 > IgorStasenko 159 > stephaneducasse 152 > avi 148 > Igor.Stasenko 128 > StephaneDucasse 85 > SeanDeNigris 81 > MarcusDenker 78 > ab 75 > GuillermoPolito 68 > tween 52 > BenjaminVanRyseghem 51 > ar 46 > di 40 > RAA 38 > alain.plantec 38 > EstebanLorenzano 35 > FernandoOlivero 33 > nice 31 > tk 29 > nk 28 > cwp 26 > dvf 22 > rr 20 > PavelKrivanek 18 > MarianoMartinezPeck 18 > yo 18 > sd 18 > bf 16 > SvenVanCaekenberghe 16 > JMM 16 > marcus.denker 14 > wiz 12 > ajh 12 > mjr 12 > cipt 10 > abc 10 > md 10 > HenrikSperreJohansen 9 > MikeRoberts 8 > AndyKellens 6 > LukasRenggli 6 > noha 6 > ClementBera 6 > jrd 6 > GastonDallOglio 6 > 2011-01-24T15:34:00+01:00 6 > DeboraFortini 5 > stephane.ducasse 5 > lr 5 > 2011-01-24T15:33:00+01:00 4 > dgd 4 > DamienCassou 4 > TestRunner 4 > bkv 4 > BG 4 > Alexandre 4 > AndrewBlack 4 > sw 4 > SimonAllier 3 > DanielAvivEstebanAllende 3 > ASB 2 > mas 2 > pmm 2 > simondenier 2 > BernardoContreras 2 > th 2 > damienpollet 2 > NicoPaez 2 > CamilloBrui 2 > sps 2 > MiguelCoba 2 > eem 2 > NikoSchwarz 2 > JavierPimas 2 > GabrielOmarCotelli 2 > mir 2 > ul 2 > 2011-01-24T15:50:00+01:00 2 > jf 2 > c 2 > ls 2 > al 2 > NorbertHartl 2 > djp 2 > AdrianLienhard 2 > TorstenBergmann 2 > AlexandreBergel 2 > tbn 2 > DiogenesMoreira 2 > GuyHylton 1 > ThierryGoubier 1 >

Jan. 30, 2013

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

by Nicolas Cellier

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(a)gmail.com> > > 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

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