1) I have an object which relies on subclasses of another class, we'll call
it AbstractHeavyLifter, to do some work. I want to be able to give a user a
choice of all the kinds of HeavyLifter available, and I don't want to
hard-code which ones they can use, since they could add new ones, etc. What
I do right now is get all the subclasses of AbstractHeavyLifter and ask each
one if I can use it in menus (abstract classes will want to say No here).
This is how the Morph menus work, and I'm 90% sure its the Right Thing, but
I wanted to check and make sure.

2) I have a Morph which has several different color properties. I want to
give access to these color properties so others can use it without
unnecessary subclassing - I hate having to subclass just to change one
little detail. Here are the options I can think of:
-- Make separate instance variables for color1, color2, etc, and a get/set
method for each of those.
-- Have a Dictionary of Name->Color associations. This is what I do now. I
like this because I have a favorite color scheme, and I can easily reuse it
across morphs. Also, it minimizes clutter. I thought this was a good idea
until I read on the pattern repository that stuffing too many things in a
Dictionary can become an AntiPattern - I'm not so sure now.
-- Put colors in Preferences. As far as I can tell, Preferences isn't
intended for per-morph or per-morph-class storage like this.

These questions are a bit dim, but I'd like to nail these things down so I
can find some morphic/squeak "best practices". I would like to have
consistency in my work and make it as accessable to others as possible.

Thanks,
Eddie