[squeak-dev] Browser whitewash

Frank Shearar frank.shearar at angband.za.org
Wed Mar 2 21:45:15 UTC 2011


On 2010/09/06 02:00, Eliot Miranda wrote:
> Hi All,
>
>      while all these cool new browsers are great I get on well with the
> standard browser and my multi-window hack around it.  But the
> multi-window hack shows up one major weakness with the default Browser,
> and that is it's use of list indices (systemCategoryListIndex
> classListIndex messageCategoryListIndex messageListIndex).  These should
> just be systemCategoryName, className, messageProtocol (categories are
> in System-Organization; classes have protocols) messageSelector.  If
> this happened the indices the browser has into the system would never
> become obsolete as does happen for example when one adds a class to a
> category, invalidating any classListIndex values into the same category,
> or systemCategoryListIndexes as happens often when the
> SystemOrganization changes on loading a package.  So if anyone is
> looking for a small useful project, someone who probably has RB chops,
> how about reimplementing Browser so that it is essentially unchanged
> except for the indexes being ripped out, buried and stomped on?

Browser already has methods like #selectedSystemCategoryName. Do these 
methods do what you want? (Never mind that internally they use the 
dreaded indices.)

Lots of places simply check the systemCategoryListIndex just to see if 
something's selected; obviously, it's easy to just replace 
"systemCategoryListIndex = 0" with "self selectedSystemCategoryName isNil"

By far the biggest hurdle to easily mucking around (apart from the fun 
of breaking essential infrastructure) is the serious lack of tests.

> If someone did this I'd get round to using menu pragmas throughout and
> integrating the RB into the base Browser.

That's a very tasty carrot you're dangling there.

I've started slowly, carefully, weeding out the index stuff: for now, 
I've just started on some baby steps (Tools-fbs.300) towards a Grand 
Refactoring.

frank



More information about the Squeak-dev mailing list