I think the bottom line is that the final word hasn't been said on
keeping objects up to date.  What do you do, for instance, if you have
circular dependencies?  And how do you keep updates from firing *too*
often?

But here are a couple of comments:

	- #step comes strictly from the GUI, whereas change/update works with
both GUI and non-GUI objects.

	- it's not much code to implement your own update mechanisms, so
programmers shouldn't feel *that* much pressure to use one of the
built-in mechanisms.

Also, Squeak let's you turn off stepping via Morph>>stopStepping.  It is
just a hint--if someone drags and drops the morph it will stop stepping
again--but it can help solve performance problems of too much stepping. 
Also, nothing stops you from having a variable stepTime, in case that is
ever useful.


Lex




ssadams at us.ibm.com wrote:
> 
> 
> Squeakers,
> How many different update mechanisms exist in Squeak today? So far you have
> the venerable change|update mechanism, the step mechanism (see
> UpdatingStringMorph for example), likely some usage of the new exception
> mechanism and possibly others I haven't found.  I think this will become
> more of a problem if we don't provide some guidance as to which should be
> used for what.
> 
> The step method relies on an external loop that will call it on a timed
> basis.  Good news is its simple to use and integrates nicely with the
> Morphic screen update process.  Bad news is you get an update whether or
> not you need it based on a timer, not the state of the value being
> displayed.  If the value requires a lot of processing each step, then you
> waste cycles when the value has not changed.
> 
> The change|update mechanism relies on the developer building (and carefully
> unbuilding) sometimes complex dependency networks.  This is how the old MVC
> system updated everything.  Good news was it was entirely demand driven and
> really enforced the MVC "seperation of concerns" paradigm.  Bad news was
> the manual management of the dependency network.
> 
> I have used and like both methods but have also been frustrated when after
> choosing one method I find I need the other.  Also, different morphs use
> different methods, which can make coordinate difficult in complex UIs.
> 
> Any ideas on how we solve this one for the longer term?
> 
> Regards,
> Sam
> 
> Sam S. Adams, IBM Distinguished Engineer, Software Group
> tie line 444-0736, outside 919-254-0736, email: ssadams at us.ibm.com
> <<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>