Hi Diego

I understand what you write and how your proposed solution works.
However from the example  of the current solution you give
I do not yet see the advantage(s) of your proposal.
What is the benefit of having two methods
instead of one

color: aColor
onColorChange

Is it to more clearly show non-standard behavior?

The main problem with the instance variable 'color'
is if I remember correctly that it is just labeled 'color'
but in many cases contains other objects.

Perhaps your solution helps to better see the difficulties
caused by this.

Regards
Hannes


<diegogomezdeck at consultar.com> wrote:
> Hi...
> 
> There are a lot of re-definitions of Morph>>color: to update some morph
> state related to the morph's color.
> 
> Let's take TickIndicatorMorph as an example:
> 
>    TickIndicatorMorph>>color: aColor
>       super color: aColor.
>       self borderColor: aColor darker
> 
> We are thinking about refactor this code with change nofification.  The
> idea is to add in Morph a method called #onColorChange.
> 
>    Morph>>color: aColor
>       "change the receiver's color"
> 
>       <... old code...>
> 
>       self onColorChange.
> 
> 
>    Morph>>onColorChange
>       "the receiver's color was just changed."
> 
>       ^ self
> 
> and refactor the TickIndicatorMorph removing TickIndicatorMorph>>color: and
> creating a new method:
> 
>    TickIndicatorMorph>>onColorChange
>       "the receiver's color was just changed."
> 
>       super onColorChange.
>       self borderColor: self color darker
> 
> There some variations to be evaluated (as send the current color to
> #onColorChange: and, eventually, send the previous and the new color.)
> 
> What do you think?
> 
> Diego Gomez Deck & MCP Team
> 
> 
> PS: The same idea can be used for #color:, #bounds:, #borderColor,
> #borderWith, etc.