On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing
<greg.ewing@xxxxxxxxxxxxxxxx> 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.)
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!
Dave