MDC forEach algorithm

JavaScript
1

Hi,
I’ve peeped into MDC forEach algorithm
but I don’t understand this step :


 var O = Object(this);

Can you explain me, please ?

Thanks in advance.

2

Sorry I forgot the link :slight_smile:
https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array/forEach

3

As far as I can tell, it doesn’t do anything. An array is already an object, so calling Object(someArray) returns the same object unchanged.

4

The guy above me is right, it doesn’t have any benefits or side-effects. Just call: var o = this;

5

That forEach algorithm is exactly the one specified in the specifications of ECMA-262 5th edition

The reason why Object(this) is used is due to the first requirement from the specifications of the Array.prototype.forEach method:

When the forEach method is called with one or two arguments, the following steps are taken:

[list=1][]Let O be the result of calling ToObject passing the this value as the argument.
[]2. Let lenValue be the result of calling the [[Get]] internal method of O with the argument “length”.
[]3. Let len be ToUint32(lenValue).
[]…[/list]

So the next question from here might be, why do the specifications require the that occurs to this value?
The answer to that is step 2, in regards to the length argument. If the this keyword is a number for example, that has no length, but an Object of that number will.

So using Object(this) is a safety device.

6

I think the more likely reason is that ECMAScript’s target audience is implementors – people who will create an actual JavaScript engine. Just look at step two: Get the length value by calling the [[Get]] internal method of O with argument “length”. That would look like this:

lenValue = O.get(“length”)

But of course that’s not how we as JavaScript programmers would write it. It wouldn’t even work. I think it’s obvious that these steps are for the underlying engine, and the author of the forEach implementation was translating engine instructions into JavaScript code. Object(this) is almost certainly a mis-translation. In the underlying engine, that step might be important, but in JavaScript land, it doesn’t serve any purpose.

7

It is a “best effort” to stay as close to the specs as possible, which also protects from “undefined” when an unexpected number is passed to the method.

8

The length value is still undefined even in Number objects.

alert( Object(42).length ); // undefined

9

undefined is another reason to use Object.

Object(undefined).length is undefined
whereas undefined.length results in a scripting failure - “TypeError: Cannot read property ‘length’ of undefined”

So using Object(this) acts as a protection mechanism from such issues.

10

I don’t think it’s even possible for “this” to be undefined. If you try it…

function f() {
    alert(this);
}

f.call(undefined);

You get the global/window object.

11

It is possible for the this keyword to be undefined.

Your situation occurs when you’re are not in “use strict” mode, where things are more flexible.

Try this out:


(function () {
    "use strict";
    
    function testFunc() {
        alert(this.length);
    }

    testFunc.call(undefined);
}());

When you use alert(Object(this).length) things are then allowed to work as we might expect.

Staying with Object(this) from the specifications ensures that it will always work, regardless of the situation.

12

Indeed. You’re correct. My mistake.

In fact, the forEach implementation even tests for this scenario, with if (this == null), which is true also when “this” is undefined. So the code seems to have dual protection.

13

Yes, the developers do seem to have gone over and above the specification requirements with that additional check.