Looking for ways to deduce selector classifications

Question

I'm working on an a SelectorClassifierAssistant object that suggests possible classifications for a method.

So far I've implemented the following strategies:

1. local classifications of same selector (ie, in the same hierarchy up and down)
2. other classifications of the same selector in other classes (sorted by frequency)
3. accessor detection (is the method a setter or a getter? ifTrue: [^#accessing] )
4. known selector prefixes (#is..., #print..., #as..., etc.)

and, if all of the above fail (ie, suggestions is empty):

5. categories of other messages sent in the method (only the ones understood in the method's class and superclasses)

Are there other known heuristics I could use?

---EDIT---

6. selectors only sent from the same class -> #private (@Carlos E. Ferro)

7. known selectors (#= #hash, etc. -> #comparing and so on)

8. empty categories (if a category is empty chances are that the user just added it for classifying the next selector.)

Answer 1

Sure. Here are a number of other well-known patterns:

instance creation

newStringBrick
    ^ GLMStringBrick new

default values

defaultDotsText
    ^ '...'

lazy initialization

items
    ^items ifNil: [ items := OrderedCollection new ]

And of course there are also lots of framework/application specific patterns. Sunit unit tests, seaside applications, magritte descriptions all have specific patterns. a very simple one is the magritte-description

descriptionArticle
    <magritteDescription>
    ^QCToOneOptionRelationDescription new
        accessor: #article;
        label: 'Article';
        options: self possibleArticles;
        priority: 40;
        classes: QCArticle allSubclasses;
        yourself.

[edit] And then the heuristics: another possibly good suggestion is the one I used last, or if you see a short repeating cycle the one that fits.

And would it be possible to find a good category for extension methods directly?

Answer 2

I think that in your last option, instead of looking at categories of messages sent in the method to classify, it would be better to look for categories of the senders of this message.

This is a heuristic that I often use.

The reason I found is that methods called from this one most likely are general services, but senders of this one consider it as a service and define an ¨area of interest¨ where this message is used.

---- EDIT ----

Another related heuristic, very simple is this: if all senders are local (this class or subclasses), then "private" is a good candidate to classify it. Methods without senders out of its class are often private services.