On 07.02.2011 05:37, David Burton wrote:
On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing
<greg.ew...@canterbury.ac.nz <mailto:greg.ew...@canterbury.ac.nz>> wrote:
David Burton wrote:
(That's because, if you are an experienced programmer, you
have learned [probably the hard way] that you really don't
want to start anything complicated in response to a click if
you're deep in the bowels of the GUI code [which has called
your callback function], since the complicated thing you start
might want to /use/ that same GUI code, and get button clicks
and menu choices of its own, leading to ever deeper recursion
in the [hopefully reentrant!] GUI code, and mind-bending
complexity and bugs.)
I can't really see how using events helps with that, because if
there's a complicated thing to be done, it needs to be done somehow
or other, and either way it's being done by a piece of code being
called from the event loop, which will hold up the GUI until it's
finished.
The difference is that with callbacks your application code is
/not/ called from the event loop, it is called from somewhere deep
inside the GUI code.
With pygame events, your application code doesn't even see the
button-click or whatever until the GUI coded has finished and exited,
so the application author doesn't have to worry about what can go
wrong if he tries to do more user interactions at that point.
With callbacks, if, when your application gets a button clock or
whatever, it then tries to do more user interactions, it will be
reentering the GUI code for a new user interaction from deep within
the GUI code itself, because the GUI code hasn't yet returned from
processing the previous user interaction, because the callback from
the application code hasn't returned. When the second user
interaction gets its result, and makes /its/ callback to the
application, both the application and the GUI are now reentrant! Two
different callbacks are now simultaneously active, and there's no
guarantee that the application code won't want to ask the user another
question, causing a /third/ level of reentrancy... /and so forth and
upward and onward, gee whiz <http://www.flounder.com/mcgrews_view.htm>!/
Dave
Hi
" from deep within the GUI code itself" <-- how does that get called?
from the event loop?
and pushing the events on the pygame event loop could be dangerous
because it is possible that there are already other events on the queue
that will change the state of the application (or gui elements) so that
at the time when your event gets processed it brakes (because the
application isn't in the state anymore it was when the event was
posted). This is a very subtle bug and difficult to catch. Not sure how
to avoid that behavior (maybe posting the gui internal events at the
front of the event queue?). Therefore I think callbacks are easier to
work with. But I'm not entirely sure how to handle reentrant calls, if
there are any (is the recursion a problem at all?). Normally only one
user interaction (event) is processed at the time. So i wonder:
"When the second user interaction gets its result, and makes
/its/ callback to the application"
How?
Just my opinion.
~DR0ID