Design thought for callbacks

[Cem Karan]

On Feb 21, 2015, at 10:55 AM, Chris Angelico <rosuav at gmail.com> wrote:

> On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan <cfkaran2 at gmail.com> wrote:
>> OK, so if I'm reading your code correctly, you're breaking the cycle in your object graph by making the GUI the owner of the callback, correct?  No other chunk of code has a reference to the callback, correct?
> 
> Correct. The GUI engine ultimately owns everything. Of course, this is
> a very simple case (imagine a little notification popup; you don't
> care about it, you don't need to know when it's been closed, the only
> event on it is "hit Close to destroy the window"), and most usage
> would have other complications, but it's not uncommon for me to build
> a GUI program that leaves everything owned by the GUI engine.
> Everything is done through callbacks. Destroy a window, clean up its
> callbacks. The main window will have an "on-deletion" callback that
> terminates the program, perhaps. It's pretty straight-forward.

How do you handle returning information?  E.g., the user types in a number and expects that to update the internal state of your code somewhere.

Thanks,
Cem Karan