On Mon, Feb 25, 2008 at 06:09:49PM +0100, cdrick wrote:
Hi
In a recent post, Matthew Fulmer explained how categories work... and I don't really see why they exist this way... Can someone explain me (historical reason, etc...)?
"In Squeak, Classes are objects, methods are objects, but categories are not. Categories are implemented interestingly. See Categorizer and subclasses. Categorizer stores two lists of Symbols; one is the list of all the categories, the other is the list of all the class names or method names, arranged so that all the names in the first part of the list are in the first category, the next few methods are in category 2, and so forth. So all the categories are is a symbol in a special list, with the mapping to classes and methods is maintained by other entities.
How would changing this work? Mostly, Browser would have to be changed significantly. OmniBrowser would probably be easier to adapt, but I have only worked with Browser, so I cannot comment."
I don't mind method categories are not first class but I find quite annoying and limited to use them (there is not even a list of usual categories except in the class side...).
Huh? when you say New Category..., you get a list with several categories you might logically want: - The most popular categories globally - The most popular categories in the superclass - Your most common category creation requests
My wish is I'd like to define categories as tags so I can attach several to method. This could be interesting to declare private method and classes extensions...
Would it be possible and would you find useful to have that possibility ? Maybe we could use a pragma like syntax.
AClass>>aMethod <category: #private category: #accessing category: #toRefactor extension: myPackage trait: TPureBehavior> ....
Matthew also said we could adopt Namespace/Category like Gulik's work on namespaces, as Namespaces are much like reified Categories.
What do you think ? Am I the only one annoyed the way method categories works (maybe another newbie reflex and maybe I don't get the power of categories the way they are...).
Power? Heh. Categories are just to document the intended use of the methods by association. I wouldn't want them to be in syntax; that would make recategorizing slow. The usual way to change the category of a method is by drag/drop, which beats typing something comment-like.
Maybe tags could use the annotation pane above the text window.
I've never really seen a reason to associate a method with more than two groups. Nonetheless, Categorizer could do that; just have the same symbol in multiple categories. Harder, though, would be correctly making a file-out or MC package with a new assumption that categories work differently than they have.