I just started reading Christian Johansen’s book ‘Test Driven JavaScript Development’, and read a little snippet I found rather interesting about the ‘this’ keyword and it’s behaviour depending on execution context. Let’s see a small example :
1 2 3 4 5 6 | |
Now, calling the diameter function on the circle behaves as expected (coming from a OO language as C#/Java).
1 2 3 4 5 | |
Fine and dandy. But when we call the diameter function in a different context with out a radius, this will not work:
1 2 3 4 5 6 7 | |
The this value is actually decided when entering the execution context. In test #2, the valuation of this does not have a radius and returns NaN. On the other hand, any other object with a radius defined may copy the function and make use of it:
1 2 3 4 5 6 7 8 9 | |
We now see that this is referring to otherObject, which obviously has a radius, meaning the function to calculate a diameter named copycat will work as expected.
A way of avoiding duplicating the diameter function, is to use the Function.Prototype.call method. One of many traits of using call is that the other object no longer needs a definition how to calculate a diameter at all. It only needs to have a radius.
The call function forces us to be explicit about what this means in the context of calling the function, expecting it as parameter:
1 2 3 4 5 6 7 8 | |