Re: [pygame] GSoC

[Casey Duncan <casey@xxxxxxxxxxx>]

That sounds even more complicated than either events or callbacks alone. 

And yes you can pass references to functions (or other python callables) around, which is one of the reasons that callbacks are so simple to code in Python.

Bear in mind that one person's nice abstraction is another's hair-pulling complexity. I can think of instances where having abstract events for various GUI interactions would be nice, but if I just want to have a button that confirm's an action, or dismisses a very simple "dialog", or even just launches the game from the title screen, I'm not sure I want to deal with the added complexity and decoupling of events.

There are so many GUI libraries out there for pygame in various states of completion, that I think it would be a great benefit if a "built-in" one didn't take too many sides. Otherwise you risk a lot of folks just going "meh" and rolling their own yet again.

-Casey

On Feb 7, 2011, at 1:11 PM, David Burton wrote:

> Or you could do it the other way around.  Instead of building event support on top of callbacks, by having callback functions which (optionally) post pygame events, you could build callback support on top of events, by posting pygame events which (optionally) contain callback functions.
> 
> In Python, functions are objects, so you can (presumably -- I haven't tried it) put a callback function reference into a GUI-generated pygame event.  When the event loop sees a GUI-generated event, it checks for the presence of a 'callback' attribute, and if one exists it would be called.
> 
> That would be an improvement over a regular callback, because the call to the callback function would be deferred until the call-stack into the GUI library had been unwound.
> 
> Dave
> 
> 
> On Mon, Feb 7, 2011 at 2:34 PM, Casey Duncan <casey@xxxxxxxxxxx> wrote:
> 
> 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
> 
>