[MCP] [Q] Color change notification
Hannes Hirzel
hannes.hirzel.squeaklist at bluewin.ch
Sun Mar 16 16:08:19 UTC 2003
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.
More information about the Squeak-dev
mailing list
|