On Sun, Feb 10, 2008 at 08:16:53PM -0600, itsme213 wrote:
> "Keith Hodges" <keith_hodges at yahoo.co.uk> wrote
> 
> > Your suggestion of Documentation classes comes but one month after I
> > suggested the very same.
> 
> Newbie alert .... Why not make package and class-category proper objects 
> with their own documentation? Is it too far-reaching a change? Or would MC 
> not handle them since they are not classes or methods? Do those who know the 
> Squeak image well think that would be a bad move? Are there some other good 
> reasons to not go that route? All of the above? :-)

Long reply. I've worked with the categorizer recently, so I
should at least tell you how it works.

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.

Also, if not done properly, it would be quite possible to
completely break the tools while transitioning from Categorizer
to Namespace/Category or whatever would replace this. Thus,
making this transition could involve a period where using any
of the browsers was impossible.

Third, to get it used, you would have to get it into a well-used
image.

This would be an idea that would fit nicely with Gulik's work on
namespaces, as Namespaces are much like reified Categories.

I don't know whether incorporating this into MC would work
nicely or not. MC was extended rather gracefully to support
traits, so categories could probably be added similarly.

So, all-in-all, it's not a bad move, just that not many people
have messed with squeak's code model in release images. However,
Traits showed us that it is not forbidden, and if it works,
changes to the code model can make it into a release image. It
would be good to do, since having eyes actively watching over
the core code and improving it would make the kernel much more
modular.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808