[SM] SMCard subCategories

Bijan Parsia bparsia at email.unc.edu
Mon Nov 25 02:20:30 UTC 2002


One thing I really like about SqueakMap is that it brings things to me. No
need to go out and find the right web page or archive: SM brings it home
to my image. Yay!

Even better, it makes me want to pound on things, extend them, fix them,
play with them, even write documentation. All to the good.

For example, I loaded up MinneStore and it seemed to work ok, in some
places, and not as ok in some others. Some things were just a bit
disobvious, though with a bit of explaining, they would be clear. Some
things needed a UnitTest or 4. Etc.

I started doing a few of these things but then realized that I had No Good
Place To Put Them. I could, of course, do the old go out and find the
right web page, contact someone, send [BUG]s and [FIX]s and set up a Swiki
page...ugh. No! I'm feeling lazy. I want *SqueakMap* to do this for me.
SqueakMap is *magic*...it can fix *anything*.

But my first impluse...to create Yet Another Package, seemed wrong. I
don't want SM cluttered up with twelve dozen tiny packages, often with
just 5 lines of code. I like the clean glowing lines of SM goodness.

But I also want everything in SqueakMap.

Basically, if each SMCard was itself also a SMCategory (or sufficiently
like one) with a certain set of subCategories (e.g., Tests, FIXs, BUGs,
Enchancments, Documenation, Request/Comments/Tips) then there'd be a
natural organization of these bits and pieces and a clear association of
them with the "parent" package.

Seems to me to fit in with the use of SqueakMap for the Harvesting
process...except that every package maintatiner gets to be their own
Harvester. (E.g., there could be ways to indicate that a particular fix
has been incorporated.)

There are a couple of ways of implementing this, though it seems fairly
straightforward, but I wanted to see what people thought first.

Cheers,
Bijan Parsia.




More information about the Squeak-dev mailing list