Eddie,

> -- Make separate instance variables for color1, color2, etc, and a get/set
> method for each of those.

An alternative to this is to use the access properties of morphs. You can
find them in the 'access properties' category in Morph.
For example:

m := Morph new.
m setProperty: #color1 toValue: Color blue.

and to retrieve the property:

aColor := m valueOfProperty: #color1.

or if you want a some type of default if there is no defined property:

aColor := m valueOfProperty: #color1 ifAbsent: [ Color green ].

This can help you avoid those pesky walkbacks if you ask a morph 'not in the
know' for its color1 property in your code.

Hopefully you'll let your creative side take over and use something for
colorful than color1 for the property name. In some sense the properties are
dynamic instance variables that you can add or delete at run time, and thus
no subclassing is required of your morphs just to change a few properties.

> -- 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.

Why in the world would you pay any attention to the repository police?

Jim