On Thursday 11 August 2016 16:21, Christian Gollwitzer wrote:
> In typical GUI code, there are usually not that many places qhere ou
> have sequential code. A simple exmaple might be a counter. Using asyncio
> and a properly integrated GUI toolkit, you could write it as (pseudo-code)
>
> async def counter():
> for i in range(10):
> button.settext("click me %d"%i)
> await button.click()
> button.disable()
> messageBox("You reached the end!")
>
> Writing that same thing in callback code to button.on_click() is
> obviously less fun and feels inverted.
I don't know how you would write it in callback fashion, but the above seems
inside out to me. It feels like COMEFROM instead of GOTO, if you understand the
analogy. Rather than
execute code in a linear fashion
until you reach a yield (GOTO), then transfer control *out*
it's
execute code in a linear fashion
control transferred *in* from somewhere else (COMEFROM)
This is how I would expect to write something like that in an event-driven way:
def mouseUp(self):
# assume self.counter is initially set to 0
self.settext("Click Me %d" % self.counter)
self.counter += 1
if self.counter == 10:
self.disable()
messageBox("You have reached the end!")
which feels natural to me. Processing of each click is independent of any other
click, and there's no non-linear transfer of control. The user clicks, the
mouseUp method is called, it runs, and it is done. Whatever persistent state
there is is part of the button itself.
I don't know whether you would call that a callback. I suppose it could be, in
the sense that you might say:
button.set_mouseup_function(mouseUp)
but I'm used to thinking of it as a property of the button.
--
Steve
--
https://mail.python.org/mailman/listinfo/python-list
