Makes sense (and it's obviously workable) - but I would personally find
it a real pain to manage (and I'm not terribly fond of adding another
layer of explicit hierarchy to go thru). I would much prefer to
right-click on a method selector, select "make private" (for example),
and have it handled according to my preferences for viewing such info
(and now the environment knows unambiguously how to classify the
selector). Since I already have the selector in its "intention revealing
category" (nice phrase), there's no further fiddling required.

One of the holy grails I quest for is the presentation of ever greater
informational bandwidth, allowing larger and larger amounts of info up
and down the scale to be seen and comprehended at once. Ever deeper
explicit hierarchies limit the view to smaller and smaller parts of the
system. It becomes the story of the three blind men and the elephant all
over again. The smallest details of complex systems are easily
comprehended - the great difficulty is in comprehending the operation
and structure of ever larger portions of the system.

Sorry, just needed to get that off my chest. :-b

-- Dwight

"Norton, Chris" wrote:
> 
> Hi Dwight & company.
> 
> [Dwight Hughes]:
> 
> "Norton, Chris" wrote:
> >
> > Actually, if we take the pains to put methods into well chosen categories,
> > we could obviate much newbie-related confusion.  E.g. put the public
> methods
> > into the "public" category!  Voila!  A self documenting interface!
> 
> Not if the "public" (or "private") category _replaces_ the proper
> informative method protocols -- it should be additional info, which
> could be shown in a number of ways (font colors, colored markers,
> filters that show only public methods,....) along with the method
> protocols.
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~
> 
> I guess I expected that y'all would just know what was floating around in my
> mind  ;-).
> 
> When I write Smalltalk methods in VSE, I usually classify them in categories
> that describe their function (intention revealing categories, if you will).
> For example:
> 
> Instance side:
>    initialization
>    printing
>    public-accessing
>    public-testing
>    private-accessing
>    private-testing
> 
> Class side:
>    creation
> 
> My rules of thumb are as follows:
> *       If the method is intended to be private, then I create/use a
> category that indicates this, like "private-accessing".
> *       If I have already got methods in a category called "accessing", then
> I rename this category to "public-accessing".
> *       If all of the methods of a certain type are considered to be public,
> then I will generally name the category by its function, like "printing"
> 
> My VSE browser creates sub-views (sort of like Bob Arnings hierarchical
> morph does), when it encounters a hyphenated word.  This nice feature "rolls
> up" my categories into "public" and "private", or whatever you've decided to
> name your top level category.
> 
> ---==> Chris