Continued from Closures and reactive programming.
Going back to closures for a second, there are some interesting facts about how they work.
Remember, we were dealing with two balls, let's recall that example, with the red closure and the green closure:
|
Nothing but two balls jumping happily up and down, no interference, no conflicts, no problem. This is clearly two separate sets of closures, each with its own ball. Remember, the closures are created inside the ball() once the up/down are referenced and passed to the animation and as we call ball() twice, we have at least two sets of two closures...
The interesting bit is now: what about inside the same function ball() though? Does each reference to up/down create a completely separate closure? Is there anything in common? I mean they obviously share the same initial ball value, but do they share anything else or did the compiler create again two completely separate closures?
Let's see - we'll swap one of the balls for a different color, after starting the adown animation (the second time, so **inside the ball()/down() closure) - which ball do you think will come up? The blue ball or the original ball?
|
If the original ball came up, then the closures share nothing but if the blue ball comes up, then the closures for up and drop in the same call to ball share the same c variable... which is it?
The point is that the closures were created once, in the beginning, when up and down were passed to creating the animation, not every time, so how do they influence each-other?
The result is pretty weird, isn't it? Let's reason through it and try to figure out what is going on...
up() is called and the red ball goes updown() is first called and it starts the adown animation while also creating the blue ball which stands still. In its closure, c is now blue, but the animation was started for the red ballup() will start the aup animation but for which color? What value is his c at that time?The answer is: for blue (which was already there so it just stands still for 1 second)... what does that mean? The two closures inside ball() share the same variable c...
In terms of... terminology, the correct way of expressing this is that we have two closures which capture the same environment (the one including the variable c). We call this twice, so we have a red environment and a green environment and two closures for each.
In scala, one could say that this is not that relevant, since the arguments are vals and immune to side effects, but this is a glimpse into what closures really are... and how evil shared mutable state is (i.e. variables of mutable collections).
One more thing to note is the obvious memory leak of the red and green balls, which now just sit there :). You would hope in scala/java that the garbage collector would collect them... if no global canvas had a reference to them!
The last thing to note is how hard it is to reason through plain reactive apps - this is a simple one and, the way the code is organized, with the animations (the calculations that take time) and the up/down reactive functions, it is pretty hard to reason through and design... let alone debug... a reactive program. We will think of some ways to simplify these soon! Keep an eye on this feed...
Cheers!
P.S. Do you know where this gets really interesting...? When you start distributing computations by means of remoting the closures... what languages do you know that can do that?
If you are interested to see more about Javascript closures, see this article.