IDL: Add forEach() method to iterable<>/maplike<>/setlike<> interfaces

Source/bindings/scripts/v8_utilities.py

Index: Source/bindings/scripts/v8_utilities.py
diff --git a/Source/bindings/scripts/v8_utilities.py b/Source/bindings/scripts/v8_utilities.py
index c4935d79d17f692a3c5eba27ac07d598fc5a8d93..f09cccab89150c22f1928fb7559e5d752e2c7a84 100644
--- a/Source/bindings/scripts/v8_utilities.py
+++ b/Source/bindings/scripts/v8_utilities.py
@@ -201,6 +201,7 @@ CALL_WITH_ARGUMENTS = {
     'ActiveWindow': 'callingDOMWindow(info.GetIsolate())',
     'FirstWindow': 'enteredDOMWindow(info.GetIsolate())',
     'Document': 'document',
+    'ThisValue': 'ScriptValue(scriptState, info.This())',

[haraken, 2015/01/27 01:56:30]

Just to confirm: Are you sure that we should use info.This(), not info.Holder()?

[Jens Widell, 2015/01/27 07:19:23]

No, I'm not sure. What's the difference between the two, exactly?

Technically, we could do without this altogether. Iterable<> would just need a
way to "find itself," since it's a mixin class and not a ScriptWrappable.
Something like

  virtual v8::Local<v8::Object> getThis() = 0;

or such would work. I figured this [CallWith=ThisValue] approach would be
simpler.

[haraken, 2015/01/27 08:47:11]

info.Holder() points to a reciever, and info.This() points to an object on which
the DOM attribute/method exists. For example, in a case of div.appendChild(),
info.Holder() points to the div, and info.This() points to
div.__proto__.__proto__.__proto__.__proto__, on which the appendChild is
defined.

 }
 # List because key order matters, as we want arguments in deterministic order
 CALL_WITH_VALUES = [
@@ -210,6 +211,7 @@ CALL_WITH_VALUES = [
     'ActiveWindow',
     'FirstWindow',
     'Document',
+    'ThisValue',
 ]