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...).
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...).
Thanks
Cédrick
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.
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
Actually I don't except for the class category... quite strage. Maybe only related to OB
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> ....
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.
I thought this could be done by the browser... the syntax could be hidden
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.
yep but 2 is more than one ;) . It also could be handy for monticello extension + personnal flags... I don't know hiw MC2 will deal with extensions though
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.
uhm ok. Thanks for answers ;)
Cédrick
On 2/26/08, cdrick cdrick65@gmail.com 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...)?
The only reason I could think of would be for speed. In the olden days, Smalltalk systems ran very slow, so code was often written in an inelegant but fast manner to get good performance.
I don't believe that the categories have been refactored much since they were originally designed back in the 80s.
Otherwise - yea, they're yuck. They would be difficult to refactor it in the squeak.org image because a lot of projects (namely, various browsers and tools) depend on their implementation.
Matthew also said we could adopt Namespace/Category like Gulik's work on
namespaces, as Namespaces are much like reified Categories.
My namespaces implementation replaces class categories, but doesn't (yet) do anything with method categories. I might leave method categories as they are for the meanwhile; it would be a low-priority refactoring to change them.
I'm never going to advocate integrating my Namespaces implementation into the squeak.org image. It would be a bad idea -- squeak.org needs to remain compatible with the large base of code out there, and my Namespaces solution breaks backwards compatibility. Instead, I'm making a fork of Squeak called SecureSqueak which will use Namespaces extensively.
Gulik.
2008/2/25, Michael van der Gulik mikevdg@gmail.com:
On 2/26/08, cdrick cdrick65@gmail.com 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...)?
The only reason I could think of would be for speed. In the olden days, Smalltalk systems ran very slow, so code was often written in an inelegant but fast manner to get good performance.
I don't believe that the categories have been refactored much since they were originally designed back in the 80s.
That was what I thought... and the problem about changing is as you say squeak need to "remain compatible with the large base of code out there"... sad reality ;)
Otherwise - yea, they're yuck. They would be difficult to refactor it in the squeak.org image because a lot of projects (namely, various browsers and tools) depend on their implementation.
I'm never going to advocate integrating my Namespaces implementation into the squeak.org image. It would be a bad idea -- squeak.org needs to remain compatible with the large base of code out there, and my Namespaces solution breaks backwards compatibility. Instead, I'm making a fork of Squeak called SecureSqueak which will use Namespaces extensively.
Interesting, I'll look at it for sure :) is it squeak-E ? where can we see it ?
Thanks
Cédrick
On Tue, Feb 26, 2008 at 10:12 AM, cdrick cdrick65@gmail.com wrote:
2008/2/25, Michael van der Gulik mikevdg@gmail.com:
On 2/26/08, cdrick cdrick65@gmail.com wrote:
Hi
I'm never going to advocate integrating my Namespaces implementation
into
the squeak.org image. It would be a bad idea -- squeak.org needs to
remain
compatible with the large base of code out there, and my Namespaces solution breaks backwards compatibility. Instead, I'm making a fork of Squeak called SecureSqueak which will use Namespaces extensively.
Interesting, I'll look at it for sure :) is it squeak-E ? where can we see it ?
No, it's not Squeak-E. That's a separate project.
Remember that its still work in progress. When its ready for general use, I'll announce it, but until then don't use it for anything other than exploring or playing around with!
http://gulik.pbwiki.com/SecureSqueak http://www.squeaksource.com/SecureSqueak
Gulik.
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
Actually I don't except for the class category... quite strage. Maybe only related to OB
In OB should also get all categories existing in superclasses in the list. The reason why you get more categories on the class-side is that there you have a longer way up to Object (Class, Behavior, etc. are also included). ;) OB has the same behavior as the refactoring browser in that respect. There I also don't get the most popular cats or the most common cat creation requests, just cats existing in the hierarchy above the current class, as far as I know.
David
beginners@lists.squeakfoundation.org
-
cdrick -
David Röthlisberger -
Matthew Fulmer -
Michael van der Gulik