Okay, I finished reading the "escaping the event loop" paper, and
there are a few points I'm unclear on. Perhaps reading the whole
dissertation will clear them up, but I thought I'd ask a few
questions.
First, what Fuchs seems to be advocating is a callback
management/scheduling scheme where the "callbacks" are continuations
(or actually, in the examples he uses, simple closures). I'm having
trouble differentiating his "actions" and plain ol' callbacks. The
most salient benefit would seem to be that you can call the actions
programatically, simplifying your flow of control, but eventually the
event scheduler is going to have to get some time or they don't get
handled.
So check me on this, you have an implicit event loop hidden in the
handler which calls your actions which have been placed in this
structure which mirrors (or at least closely resembles) the widget
hierarchy. You can call actions programatically which create
"synchronous" dialogues and such while still getting your windows
refreshed and such because they're actually asynchronous and just seem
synchronous because the manager is routing the events for you. Is this
all correct?
In any case, it's interesting reading, and perhaps I can make use of
something like it. The actual mechanism he describes seems a little
baroque for my needs, though.
|