Smalltalk › Pharo › Pharo Smalltalk Developers

I hate 'as yet unclassified'

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

55 messages Options

123

Stéphane Ducasse

Re: I hate 'as yet unclassified'

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
>

Stéphane Ducasse

Re: I hate 'as yet unclassified'

In reply to this post by Sven Van Caekenberghe-2

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…

Stéphane Ducasse

Re: I hate 'as yet unclassified'

In reply to this post by NorbertHartl

> To be honest I have problems understanding why method categorization is so important.

Because I do not like to live in an environment where there are papers on the floor.
Did you read the pragmatic programmer book? I dislike these guys personally but the first book is excellent.
"No broken window"

Why do we remove deadcode? why do we comment classes?

Stef

> Often I don't care a single bit about categories because I don't understand them. I often categorize just to make lint happy :)
> What is the use? Declaring usage patterns? Declaring visibility? Use as method extensions marker? anything you like just classify? I can understand that it can help making the access of certain methods of a class easier. But that is particular true for classes with a lot of methods. Most of the classes are rather small. In most of my own developments I would consider most huge classes a design problem in my code. So I would try to fix that.
> And finally it is not easy to learn about them because the browser is not helping. If you browse through the methods of a class the category pane doesn't get updated. So even if I want to learn by getting used to them it is hard.
>
> I would make the none categorized term weaker by naming it "uncategorizied" so at least I have the change to deliberately not categorizing my methods without being annoyed by someones opinion about what is essential.
>
> my 2 cents,
>
> Norbert

Stéphane Ducasse

Re: I hate 'as yet unclassified'

In reply to this post by Camillo Bruni-3

Cool
Camillo can I see the code?
I was planning to look for the old autocategoriser.

Stef

> I just wrote a simple classifier which is going to be used in Nautilus.
> Basically it is an extensions of the existing code.
>
> Methods are classified using the following rules:
>
> 1. known prefixes (initialize.* => initialize-reseleas, test.* -> testing..)
could we have initialize and not initialize-release

> 2. getters and setters of instance variables
> 3. know protocols of super implementors
> 4. gather all implementors in the system and choose the most used protocol.
>
> I guess that will cover most stuff, of course known prefixes will have to be
> extended...
>
>
> On 2013-01-30, at 20:52, Chris Muller <[hidden email]> 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.
>>
>
>

Stéphane Ducasse

Re: I hate 'as yet unclassified'

In reply to this post by Nicolas Cellier

> First, these are not categories. categories are for classes.
> These are protocols.

Yes :)

>
> A protocol is like an interface, or you can view it as services
> offered by the instances of this class...
> For example take a look at Number you have
> 'comparing', is a very generic service, so that any object can be in a set
> numbers have this property to have full order, so they offer a bit
> more than = and hash
> 'printing' a very generic Object protocol too for interacting
> (inspectors, debuggers...)
> 'arithmetic' is some more specialized service offered by numbers
> 'mathematical functions' too.
>
> If the classification helps a lot, IMHO it's not only related to the
> number of messages.
> It helps to declare/discover which service will be offered, and those
> can be completely transversal (printing vs comparing).
>
> 'private' has a value too, as there is no service to expect here...
>
> So I have to disagree. I see these as essentials.

me too :)

Stéphane Ducasse

Re: I hate 'as yet unclassified'

In reply to this post by Nicolas Cellier

On Jan 30, 2013, at 7:20 PM, Nicolas Cellier wrote:

> In st-80 these were protocols and the name make you think of it differently.

nicolas normally in the book we use protocols and I normally picky about it.
I do not like categories even for classes :)
So I will check.

Stef

> If you want to continue thinking of it in term of category, then I understand your miss-conception.
> I'm curious to know when the term category was introduced...
> Maybe with Monticello where it means 'Package'?
> Clever hacks sometimes are not that clever...
>
> Nicolas
>
> 2013/1/30 Norbert Hartl <[hidden email]>
>
> Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <[hidden email]>:
>
>> First, these are not categories. categories are for classes.
>> These are protocols.
>
> Well, that's one reason I took the term "uncategorized". If I take the context menu in the category (!) pane I see
>
> <Bildschirmfoto 2013-01-30 um 22.17.17.png>
>
> So it looks to me that pharo has the notion of categories for organizing methods.
>
>>
>> A protocol is like an interface, or you can view it as services
>> offered by the instances of this class...
>> For example take a look at Number you have
>> 'comparing', is a very generic service, so that any object can be in a set
>> numbers have this property to have full order, so they offer a bit
>> more than = and hash
>> 'printing' a very generic Object protocol too for interacting
>> (inspectors, debuggers...)
>> 'arithmetic' is some more specialized service offered by numbers
>> 'mathematical functions' too.
>>
> The category is a service for humans made by humans. The methods in e.g. "comparing" would work the same without a category. I think we can agree on the fact that relying on categories in code is mostly something not desirable.
>
>> If the classification helps a lot, IMHO it's not only related to the
>> number of messages.
>> It helps to declare/discover which service will be offered, and those
>> can be completely transversal (printing vs comparing).
>>
>> 'private' has a value too, as there is no service to expect here...
>>
>> So I have to disagree. I see these as essentials.
>>
> I did not decline that categories _can_ be useful and in fact they are. I'm also inclined to say that it is a good thing having all methods categorized in the distributed pharo image. So lint rules and such testing is good. But at the same time I don't see a point in enforcing it for everyone by choosing a stronger or even insulting term (at that point I decided to reply) for uncategorized methods.
>
> Norbert
>
>> Nicolas
>>
>> 2013/1/30 Norbert Hartl <[hidden email]>:
>>>
>>> Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse <[hidden email]>:
>>>
>>>> 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
>>
>
>

Camillo Bruni-3

Re: I hate 'as yet unclassified'

In reply to this post by Stéphane Ducasse

I was just waiting for the google issue tracker to come back to life...

https://code.google.com/p/pharo/issues/detail?id=7373

=> Slice in Inbox

the major problem I have now, is that wrong categorizations might easily
spread :P, the sepll-fleu and the space - vi rus, are very common...

On 2013-01-31, at 00:43, Stéphane Ducasse <[hidden email]> wrote:
> Cool
> Camillo can I see the code?
> I was planning to look for the old autocategoriser.
>
> Stef

Nicolas Cellier

Re: I hate 'as yet unclassified'

In reply to this post by Stéphane Ducasse

2013/1/31 Stéphane Ducasse <[hidden email]>:

>
> On Jan 30, 2013, at 7:20 PM, Nicolas Cellier wrote:
>
>> In st-80 these were protocols and the name make you think of it differently.
>
> nicolas normally in the book we use protocols and I normally picky about it.
> I do not like categories even for classes :)
> So I will check.
>
> Stef
>

I thought it was due to Monticello, because both class category/method
category must match to make a pakage...
But browsing a Squeak 1.3 image, i see some Browser protocol
classified 'message category list', so it must be a rather ancient
naming...

I have vague recollection of st-80 v2 using same object to categorize
classes and methods, so maybe it was already named category there
too...

For my part, I still prefer to think in term of protocol, numbers have
protocol for doing arithmetic, for comparing, for printing,...

Nicolas

>> If you want to continue thinking of it in term of category, then I understand your miss-conception.
>> I'm curious to know when the term category was introduced...
>> Maybe with Monticello where it means 'Package'?
>> Clever hacks sometimes are not that clever...
>>
>> Nicolas
>>
>> 2013/1/30 Norbert Hartl <[hidden email]>
>>
>> Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <[hidden email]>:
>>
>>> First, these are not categories. categories are for classes.
>>> These are protocols.
>>
>> Well, that's one reason I took the term "uncategorized". If I take the context menu in the category (!) pane I see
>>
>> <Bildschirmfoto 2013-01-30 um 22.17.17.png>
>>
>> So it looks to me that pharo has the notion of categories for organizing methods.
>>
>>>
>>> A protocol is like an interface, or you can view it as services
>>> offered by the instances of this class...
>>> For example take a look at Number you have
>>> 'comparing', is a very generic service, so that any object can be in a set
>>> numbers have this property to have full order, so they offer a bit
>>> more than = and hash
>>> 'printing' a very generic Object protocol too for interacting
>>> (inspectors, debuggers...)
>>> 'arithmetic' is some more specialized service offered by numbers
>>> 'mathematical functions' too.
>>>
>> The category is a service for humans made by humans. The methods in e.g. "comparing" would work the same without a category. I think we can agree on the fact that relying on categories in code is mostly something not desirable.
>>
>>> If the classification helps a lot, IMHO it's not only related to the
>>> number of messages.
>>> It helps to declare/discover which service will be offered, and those
>>> can be completely transversal (printing vs comparing).
>>>
>>> 'private' has a value too, as there is no service to expect here...
>>>
>>> So I have to disagree. I see these as essentials.
>>>
>> I did not decline that categories _can_ be useful and in fact they are. I'm also inclined to say that it is a good thing having all methods categorized in the distributed pharo image. So lint rules and such testing is good. But at the same time I don't see a point in enforcing it for everyone by choosing a stronger or even insulting term (at that point I decided to reply) for uncategorized methods.
>>
>> Norbert
>>
>>> Nicolas
>>>
>>> 2013/1/30 Norbert Hartl <[hidden email]>:
>>>>
>>>> Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse <[hidden email]>:
>>>>
>>>>> 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
>>>
>>
>>
>
>

cbc

Re: I hate 'as yet unclassified'

In reply to this post by Chris Muller-3

On Wed, Jan 30, 2013 at 12:53 PM, Chris Muller <[hidden email]> wrote:

On Wed, Jan 30, 2013 at 2:40 PM, Camillo Bruni <[hidden email]> wrote:
> I just wrote a simple classifier which is going to be used in Nautilus.
> Basically it is an extensions of the existing code.
>

[snip]

> 3. know protocols of super implementors

I admit that is a good one.

I think this is execllent. I'd appreciate is a lot.

> 4. gather all implementors in the system and choose the most used protocol.

Not so much this one. If you limited the scope (say to siblings - subclasses of it's superclass of the same level, ignoring Object as a superclass), I think this would also be excellent. Usually when I'm creating a set of related classes, I'll wind up making the categories (or protocols) similar - any help here is indeed help.

-Chris

Sean P. DeNigris

Re: I hate 'as yet unclassified'

Administrator

In reply to this post by Stephan Eggermont-3

Stephan Eggermont wrote

By author

gvc 1307
GaryChambers 195
186
AlainPlantec 123
CamilloBruni 89
stephaneducasse 78
SeanDeNigris 72

Sweet, I moved up in the rankings :) I'm so proud...

Cheers,
Sean

Ben Coman

Re: I hate 'as yet unclassified'

In reply to this post by Camillo Bruni-3

Camillo Bruni wrote:

> I was just waiting for the google issue tracker to come back to life...
>
> https://code.google.com/p/pharo/issues/detail?id=7373
>
> => Slice in Inbox
>
> the major problem I have now, is that wrong categorizations might easily
> spread :P, the sepll-fleu and the space - vi rus, are very common...
>
>

Can the auto-categorization mark such methods as "auto-categorized" ?
So that later if it doesn't seem quite right, a human can make a better
judgment rather than assuming someone else had already made such a
judgment for some-good-reason. In reality perhaps such
re-categorization wouldn't happen a lot, but "being at least able to"
make such judgment increases confidence in the system, which can be
subtly undermined by automated tools (and anyway I hate throwing away
information that is easily available at the time). This wouldn't need
any tool support straight away, but at least the data is captured for
later use.

Frank Shearar-3

Re: I hate 'as yet unclassified'

In reply to this post by Nicolas Cellier

On 30 January 2013 22:36, Nicolas Cellier <[hidden email]> wrote:

2013/1/30 Frank Shearar <[hidden email]>

On 30 January 2013 22:20, Nicolas Cellier <[hidden email]> wrote:

In st-80 these were protocols and the name make you think of it differently.
If you want to continue thinking of it in term of category, then I understand your miss-conception.
I'm curious to know when the term category was introduced...
Maybe with Monticello where it means 'Package'?
Clever hacks sometimes are not that clever...

Nicolas

Sure. I also remember people talking about "the protocol of Foo", meaning the set of messages that Foo understood. That's how the Objective-C and Clojure people understand the term, for what it's worth.

Sometimes the those who came before named things poorly... :)

I don't know what you think was named poorly...
I just wonder, in term of communicating by sending messages, what is the best name for defining the set of messages an object can understand? Category or protocol ;)

My understanding of "protocol" means "how do I talk to this thing?" while yours is "these sets of messages for this object do similar things". 'testing' giving you the _subset_ of an object's understood messages that return Boolean, for instance. "What's the testing protocol of this object?" sounds wrong to my ears.

Now you could say "the things that make something Streamlike" (what I'd call a protocol) "are the things that Stream implements", and that's really what I'd like to aim for. <<foo supports: Stream>> would return true if foo supported the set of messages that Stream supported - if it understood the _protocol_ of Stream.

Ah, and from that link we see "Every object in Smalltalk, even a lowly integer, has a set of messages, a protocol, that defines the explicit communication to which that object can respond." (I may well be cherrypicking; I haven't read the paper properly yet.)

frank

Nicolas

frank

2013/1/30 Norbert Hartl <[hidden email]>

Am 30.01.2013 um 22:03 schrieb Nicolas Cellier <[hidden email]>:

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 <[hidden email]>:

Am 29.01.2013 um 16:57 schrieb Stéphane Ducasse <[hidden email]>:

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

Camillo Bruni-3

Re: I hate 'as yet unclassified'

In reply to this post by Ben Coman

On 2013-01-31, at 03:53, Ben Coman <[hidden email]> wrote:

>
> Camillo Bruni wrote:
>> I was just waiting for the google issue tracker to come back to life...
>>
>> https://code.google.com/p/pharo/issues/detail?id=7373
>>
>> => Slice in Inbox
>>
>> the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common...
>>
>>
>
> Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.

the categorization will happen only upon user interaction.
hence I think such a control is not needed directly.
Feel free to extend the current classifier to support it, the code is
fairly simple..

S Krish

Re: I hate 'as yet unclassified'

Auto categorization in the old browser: " Categorize all uncategorized " had simple rules especially overridden methods / known methods in their known categories..

That would help greatly for most developers, more so the beginners to get a good feel of recommended categorization.

But can auto categorization cause wrong labeling may need to weighed, better to leave it uncategorized in that case.

****************

PS: At work on a VAGE code, I was pointing to the exact same issue of missing categorization over last many years..!.. The lack of categorization limits comprehension of the codebase... especially of code built over 20 yrs.

On Thursday, January 31, 2013, Camillo Bruni wrote:

On 2013-01-31, at 03:53, Ben Coman <[hidden email]> wrote:

>
> Camillo Bruni wrote:
>> I was just waiting for the google issue tracker to come back to life...
>>
>> https://code.google.com/p/pharo/issues/detail?id=7373
>>
>> => Slice in Inbox
>>
>> the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common...
>>
>>
>
> Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.

the categorization will happen only upon user interaction.
hence I think such a control is not needed directly.
Feel free to extend the current classifier to support it, the code is
fairly simple..

Fernando olivero-2

Re: I hate 'as yet unclassified'

In reply to this post by Camillo Bruni-3

Hi, i think i found a hint on the questions posed in this thread: why the Smalltalk tools moved from "protocols" to "categories".

Maybe it happened when Morphic took over MVC? Because the term categories is used in SELF, look at the outliner in the attached image. Morphic originally was included in SELF, and later ported to Smalltalk.

Fernando

On Thu, Jan 31, 2013 at 12:28 PM, S Krish <[hidden email]> wrote:

Auto categorization in the old browser: " Categorize all uncategorized " had simple rules especially overridden methods / known methods in their known categories..

That would help greatly for most developers, more so the beginners to get a good feel of recommended categorization.

But can auto categorization cause wrong labeling may need to weighed, better to leave it uncategorized in that case.

****************
PS: At work on a VAGE code, I was pointing to the exact same issue of missing categorization over last many years..!.. The lack of categorization limits comprehension of the codebase... especially of code built over 20 yrs.

On Thursday, January 31, 2013, Camillo Bruni wrote:

On 2013-01-31, at 03:53, Ben Coman <[hidden email]> wrote:

>
> Camillo Bruni wrote:
>> I was just waiting for the google issue tracker to come back to life...
>>
>> https://code.google.com/p/pharo/issues/detail?id=7373
>>
>> => Slice in Inbox
>>
>> the major problem I have now, is that wrong categorizations might easily spread :P, the sepll-fleu and the space - vi rus, are very common...
>>
>>
>
> Can the auto-categorization mark such methods as "auto-categorized" ? So that later if it doesn't seem quite right, a human can make a better judgment rather than assuming someone else had already made such a judgment for some-good-reason. In reality perhaps such re-categorization wouldn't happen a lot, but "being at least able to" make such judgment increases confidence in the system, which can be subtly undermined by automated tools (and anyway I hate throwing away information that is easily available at the time). This wouldn't need any tool support straight away, but at least the data is captured for later use.

the categorization will happen only upon user interaction.
hence I think such a control is not needed directly.
Feel free to extend the current classifier to support it, the code is
fairly simple..

self-outliner.pdf (59K) Download Attachment

123