Thanks to everyone who joined in this discussion, it was very helpful. I think I will go with Casey's idea, and support both methods, leaving it to the user to decide which method to use.
Thanks, Sam Bull On Mon, 2011-02-07 at 12:34 -0700, Casey Duncan wrote: > 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 >
signature.asc
Description: This is a digitally signed message part
