On Wed, 8 Aug 2018 19:36:10 -0400 David Vanderson <david.vander...@gmail.com> wrote:
> > Is there a better solution to this problem? How do mature > > notifier/subscriber frameworks deal with these kind of problems? > > > The most straightforward solution I've seen puts the responsibility > on the view. When the view gets a 'model-change, set a flag, change > the GUI, unset the flag. While the flag is set, the view will not > send 'view-change events. > > It's worked well for me, but maybe not at the level you're looking > for. That's how I did it in the past, too. The disadvantage of this solution is that it puts the burden of cycle detection on the client of an event library rather than the library itself. It also seems to be principally error-prone, because in theory external events (e.g. user interaction) can occur during the handling of the received event. The problem does not just occur with model/view patterns, it may occur with any asynchronous event handling that at some time later may trigger a new event in response. I suppose this is a general misfeature of event-based programming and was wondering whether there is something better available in general. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
