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 |
|