4 ms·

Globalized message passing (aka events) has flaws. You basically have to structure your events into namespaces, module:channel:event. When entering code written

Globalized message passing (aka events) has flaws. You basically have to structure your events into namespaces, module:channel:event. When entering code written by someone else, you have to gather where events are going to and coming from; if you're lucky you solve this with a grep search, but if event strings are built in a dynamic way, you won't find it without prior knowledge. There needs to be a better solution.

malandrew 13y ago
Build Event Graphs and wire them up to Sources (input) and Side Effects (output) to create Event Networks, that can be turned on, paused or dismantled. This is the approach used in Haskell's Reactive Banana and it's declarative, making it very clean and easy to read. Since it's functional, you can probably write tools to spit out all the possible event graphs in an app and the event networks that are actually wire up by the app when in use. Better yet, you can make a module that records all the events at the Source input with timestamps and then use a timeline scrubber to play them forwards and backwards in many cases. I do this in an app I am building with animations. Every single thing that can be animated implements a function that takes an input from 0.0 to 1.0. Such functions can include changing opacity, z-depth, height, width, position along a bezier curve, etc. For custom animations that are state dependent, I will often have a higher order function that takes some state of the world as an argument, creates a data structure representing the desired custom animation based on that state that can be looked up from 0.0 to 1.0. That function then returns another function that takes an state from [0..1] that is used to lookup the animation state in that data structure referenced by closure. When I have lots of animations occurring simultaneously that need to be choreographed, I just create a state emitter that goes from 0 to 1 linearly over a predetermined amount of time. That state emitter can be mapped to functions that change the curve from linear to all sorts of things like quadratic functions, step functions, binary on/off functions, etc. This all allows me to orchestrate a ton of animations, making things like this[0] and this[1] trivial. [0] http://watchingapple.com/2009/11/a-closer-look-at-iphone-transition-animations/ http://watchingapple.com/2009/11/a-closer-look-at-iphone-tra... [1] http://watchingapple.com/2007/06/slide-to-unlock/ http://watchingapple.com/2007/06/slide-to-unlock/

malandrew 13y ago

Build Event Graphs and wire them up to Sources (input) and Side Effects (output) to create Event Networks, that can be turned on, paused or dismantled. This is the approach used in Haskell's Reactive Banana and it's declarative, making it very clean and easy to read. Since it's functional, you can probably write tools to spit out all the possible event graphs in an app and the event networks that are actually wire up by the app when in use. Better yet, you can make a module that records all the events at the Source input with timestamps and then use a timeline scrubber to play them forwards and backwards in many cases. I do this in an app I am building with animations. Every single thing that can be animated implements a function that takes an input from 0.0 to 1.0. Such functions can include changing opacity, z-depth, height, width, position along a bezier curve, etc. For custom animations that are state dependent, I will often have a higher order function that takes some state of the world as an argument, creates a data structure representing the desired custom animation based on that state that can be looked up from 0.0 to 1.0. That function then returns another function that takes an state from [0..1] that is used to lookup the animation state in that data structure referenced by closure. When I have lots of animations occurring simultaneously that need to be choreographed, I just create a state emitter that goes from 0 to 1 linearly over a predetermined amount of time. That state emitter can be mapped to functions that change the curve from linear to all sorts of things like quadratic functions, step functions, binary on/off functions, etc. This all allows me to orchestrate a ton of animations, making things like this[0] and this[1] trivial. [0] http://watchingapple.com/2009/11/a-closer-look-at-iphone-transition-animations/ http://watchingapple.com/2009/11/a-closer-look-at-iphone-tra... [1] http://watchingapple.com/2007/06/slide-to-unlock/ http://watchingapple.com/2007/06/slide-to-unlock/