It seems that Bill Spight wrote:
> 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?

Yes, exactly.

color: seems like a simple accessor. We saw that sometimes it has "hidden"
behavior, unexpected for the reader. The same applies in many cases to
extent:.

German Morales
(MCP team)