On Feb 6, 2011, at 9:37 PM, David Burton wrote: > On Sun, Feb 6, 2011 at 4:42 PM, Greg Ewing <[email protected]> > 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
