Backward-compatible suggestion to make touch API more functional
Des last edited by
[EDIT:] Please ignore this post!! I figured out a clean way to do this without any API change, just defining one Scene subclass and using composition from there on.
Touch is a more stateful interaction than many others. The touch API is
touch_began(), touch_moved(), and touch_ended(), and all three take a scene and a touch event, and expect nothing back. My touch interactions need to build up some state across these three, and this API forces me to save the state myself: imperative, increases subclassing of scene, and rules out a functional style game architecture.
If the API could accept the return value from each call, and provide it forward to the next one, I am free to code more functionally. e.g.
... touch_began(self, touch) -> my code returns A, can use self, touch ... touch_moved(self, touch, A) -> my code returns B1, can use A, self, touch ... touch_moved(self, touch, B1) -> my code returns B2, can use B1, self, touch ... touch_ended(self, touch, B2) -> my code does not return anything useful
Tracking the path could be cleanly functional if I wanted:
def touch_began(self, touch): return [touch.location] def touch_moved(self, touch, p): return [touch.location] + p def touch_ended(self, touch, p): do_whatever with accumulated path p
Perhaps Pythonista could include the return values from my code in the next call after checking arity of these methods? Or perhaps it could have a
touch_ended_fversion that passed this extra information around? In either case I'm sure I am oversimplifying the impact :)
Love the tool!