167392 - Technical issues on resolution of |this| inside function calls

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Phil Schwartau]

The URL is a testcase Waldemar created while considering bug 139645.
Here are some of Waldemar's comments:

---
Every function closes over the 'this' variable -- it does not inherit
it from its outer lexical scope.  The caller always provides the value
to put into the 'this' variable.  To see in detail where it comes from,
look at ECMA 11.2.3:

When evaluating a call expression 'f(args)', the subexpression 'f' is evaluated
and then GetValue is called on it to get the function.  If 'f' is not an lvalue,
'this' gets the value null, which the called function then turns into a global
object.  If 'f' is an lvalue, 'this' gets the value obtained by GetBase (ECMA
8.7).  If 'f' is a member expression such as 'x.y', then the base is the value
of 'x'.  If 'f' is a simple identifier reference such as 'y', then the base is
whatever scope object contains the variable 'y'.


According to this, the behavior on the examples in the prior comments is
correct.  |executeNow| passes its local scope as the 'this' argument to 'f'. 
However, I tried different, slightly weirder examples which don't match the
ECMA spec:

js> this.x = "g"
g
js> x
g
js> function show() {return this.x}
js> show()
g
js> function a() {
var x = "h";
return show();
}
js> a()
g

So far so good, but:

js> function b() {
var x = "i";
var y = show;
return y();
}
js> b()
g

Here I'd expect show's this value to be b's activation object and get
the answer "i" instead of "g".

js> function b() {
var x = "i";
var y = function() {return this.x};
return y();
}
js> b()
g

Same thing, following a strict ECMA interpretation.

Before trying to fix this case, let's see what Internet Explorer does.
If it behaves as above (returns "g"), then I'd be more inclined to mark
this as a bug in the standard than to fix it in our implementation.
---

Comment 1

[Phil Schwartau]

Waldemar's testcase is:

<script type="text/javascript" language="JavaScript">

function show(t) {
  document.write("<P>Show: "+t+" = "+this.x+"<\/P>");
}

this.x = "g";
show("called globally");

function a() {
  var x = "h";
  show("called from a");
}

function b() {
  var x = "i";
  var y = show;
  return y("called from b");
}

var c = {x:"k", y:show};

a();
b();
c.y("called from c");
with (c) {
  y("called via with from c");
  var z = y;
  z("called via with and rename from c");
  var c2 = function() {
    y("called via with and local scope from c");
    var z2 = y;
    z2("called via with and local scope rename from c");
  }
  c2();
}
</SCRIPT>



Waldemar notes, "According to ECMA, the output of the test should be:

ThisTest:
Show: called globally = g
Show: called from a = g
Show: called from b = *i*
Show: called from c = k
Show: called via with from c = k
Show: called via with and rename from c = g
Show: called via with and local scope from c = k
Show: called via with and local scope rename from c = *k*.

Trying it on both NN6 and Mac IE, I get:

ThisTest:
Show: called globally = g
Show: called from a = g
Show: called from b = g
Show: called from c = k
Show: called via with from c = k
Show: called via with and rename from c = g
Show: called via with and local scope from c = k
Show: called via with and local scope rename from c = g.

(My IE doesn't show the last two lines because it doesn't like
nested functions for some reason.)

Although this is non-ECMA, I think it's a saner behavior than what ECMA
specifies and should be treated as a bug in the spec. 

Any other data points?"

Comment 2

[Bob Clary [:bc] (inactive)]

ff trunk, msie6 and opera 7.6 preview on winxpsp2 all agree with 

Show: called globally = g
Show: called from a = g
Show: called from b = g
Show: called from c = k
Show: called via with from c = k
Show: called via with and rename from c = g
Show: called via with and local scope from c = k
Show: called via with and local scope rename from c = g

Comment 3

[Bob Clary [:bc] (inactive)]

Brendan, WONTFIX this one?

Comment 4

[Brendan Eich [:brendan]]

ECMA-262 Edition 3, 11.2.3 step 7 says:

7. If Result(6) is an activation object, Result(7) is null. Otherwise, Result(7)
is the same as Result(6).

So the words in comment 0:

    Here I'd expect show's this value to be b's activation object and get the
    answer "i" instead of "g".

are contradicted by the spec.  INVALID, not WONTFIX.

/be