[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] GSoC



On Feb 6, 2011, at 9:37 PM, David Burton wrote:

> 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.)
> 
> 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!

IMHO callbacks vs. events are an architecture opinion that a library should not force upon an application. It seems to me like little extra work to support both. Actually it is pretty easy to imagine building event support simply on top of callbacks. All the callbacks would do is post events.

Forcing simple apps to always use events though sounds like a loss. There are plenty of games where the added complexity of events buys you nothing, and just makes the code more complex and harder to follow. In more complex GUI apps, events can be a win, or folks might just prefer that approach over callbacks. So making the library non-religious on this issue would be a good thing.

-Casey