Dear Diego,

Hannes:
> > What is the benefit of having two methods
> > instead of one
> >
> > color: aColor
> > onColorChange
> >
> > Is it to more clearly show non-standard behavior?
> 

Diego:
> The idea is to give more semantic value to the message names.  Some code on
> #onColorChange clearly shows an intention to the reader.

I believe that I misunderstood you before. Let me try again. :-)

Currently, Morph>>color: aColor means, "Set the receiver's color. 
Directly set the color if appropriate, else go by way of fillStyle."
(The method comment. -- Which, BTW, should add something about setting
the initial color with #defaultColor.) But several subclasses redefine
#color: aColor to set the receiver's color to aColor *and* do something
else. So the proposal is to change the meaning of Morph>>color: aColor
to this: "Set the receiver's color.  Directly set the color if
appropriate, else go by way of fillStyle. And then maybe do something
else." Then, many of these subclasses would *not* redefine #color: but
would instead have a method, #onColorChange, where they put the
something else.

Doing that would make it clear, upon viewing the methods for those
subclasses, that if they change their color, they also do something
else. While we might infer that from their redefinition of #color:, this
way makes it clear. 

Do I understand you now?

Thanks,

Bill