this confusion

Stevo said the following on 8/8/2007 5:23 PM:
> Simplified example code which can be copy/pasted and will exhibit the
> problem.
>
> var ob={id:2};
> ob.alertid=function(){alert("id="+this.id);}
> ob.funcs=[ob.alertid];
> ob.testalert=function(){
> this.alertid(); //this works
> this.funcs[0](); //this doesn't
> }
>
> ob.testalert();
>
> I have an object with an id property. The alertid function alerts that
> id property if it's called directly, but not if it's called via an array
> of function pointers. I don't understand the difference. Why is 'this'
> different in those two cases. It's the same object method isn't it.
>
> The output is:
>
> id=2
> id=undefined

I am no expert on "this" but I do know that "this" and what it refers to
depends directly on how a function is called and it - typically - points
to the entity that called it. Richard Cornford has, and will be for a
while, the best resource for an answer on "this" and sometimes he is
help with "that" as well
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

On Aug 8, 5:23 pm, Stevo <ple... RemoveThis @spam-me.com> wrote:
> Simplified example code which can be copy/pasted and will exhibit the
> problem.
>
> var ob={id:2};
> ob.alertid=function(){alert("id="+this.id);}
> ob.funcs=[ob.alertid];
> ob.testalert=function(){
> this.alertid(); //this works

Right. Because you called a method of the ob object. In this case,
"this" is ob, which has an id property.

> this.funcs[0](); //this doesn't

funcs[0] holds a reference to an anonymous function. The fact that ob
has a property (alertid method) that references it as well is
meaningless. In this case, "this" refers to the anonymous function,
which has no id property.

Stevo wrote:
> [...]
> var ob={id:2};
> ob.alertid=function(){alert("id="+this.id);}
> ob.funcs=[ob.alertid];
> ob.testalert=function(){
> this.alertid(); //this works
> this.funcs[0](); //this doesn't
> }
>
> ob.testalert();
>
> I have an object with an id property. The alertid function alerts that
> id property if it's called directly, but not if it's called via an array
> of function pointers. I don't understand the difference. Why is 'this'
> different in those two cases. It's the same object method isn't it.

It is the same Function object. But it is called differently.

> The output is:
>
> id=2
> id=undefined

With the second call you are calling the method as the property of the Array
object, not of the owner of the property (`funcs') the reference to it is
assigned to (`ob'). Try this

Array.prototype.toString = function()
{
return "[" + this.join(", ") + "]";
};

var id = 2;

var ob = {
id: 42,

alertid: function()
{
window.alert([
"this.id = " + this.id,
"this = " + this,
"typeof this = " + typeof this,
"this.constructor = " + this.constructor
].join(",\n"));
}
};

ob.funcs = [ob.alertid];

ob.testalert = function()
{
this.alertid(); // this.constructor == Object
this.funcs[0](); // this.constructor == Array
};

ob.testalert();


HTH

PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

David Mark wrote:
> In this case, "this" refers to the anonymous function,
> which has no id property.

Thanks David, Randy, Thomas and Rob. You all said the same thing
basically, this differs depending on how it's called. Excellent link
Rob, that's one to bookmark.

I've altered the alertid function to add 'that' and it now works.

var ob={id:2};
ob.alertid=function(){var that=ob;alert("id="+that.id);}
ob.funcs=[ob.alertid];
ob.testalert=function(){
this.alertid();
this.funcs[0]();
}
ob.testalert();

That has the name ob hard-coded in the alertid function though. I wonder
if it's possible to create 'that' without knowing the name of the
object? Take the following example with ??? where I don't know what to set:

var ob_a={id:"a"};
var ob_b={id:"b"};
var alertid=function(){var that=???;alert("id="+that.id);}
ob_a.alertid=alertid;
ob_b.alertid=alertid;

I'm guessing that there's no way to define 'that' which would work for
both objects there, and I'd have to define an anonymous function for
each object, with hard-coded references to ob_a and ob_b in them like so:

var ob_a={id:"a"};
var ob_b={id:"b"};
ob_a.alertid=function(){var that=ob_a;alert("id="+that.id);};
ob_b.alertid=function(){var that=ob_b;alert("id="+that.id);}

Stevo wrote:
> [...]
> var ob={id:2};
> ob.alertid=function(){var that=ob;alert("id="+that.id);}
> ob.funcs=[ob.alertid];
> ob.testalert=function(){
> this.alertid();
> this.funcs[0]();
> }
> ob.testalert();
>
> That has the name ob hard-coded in the alertid function though. I wonder
> if it's possible to create 'that' without knowing the name of the
> object?

No, it can't be (other than parsing the source code somehow). Objects have
no name, they have identity (two compared object "instances"[1] are either
the same object or they are different objects). `ob' is but the identifier
of only one possible reference of that object (in fact, the name of a
property of the Variable Object, the Global Object here). And since a
property can be also an object reference (as you have observed now with the
Array object), you cannot tell the owner(s) of a property (apart) by looking
at the property value. At least not in current ECMAScript implementations.


PointedEars
___________
[1] This has nothing to do with instantiation or classes. I just can't
think of a better term for this theoretical language construct.
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

Stevo wrote:
> [...] I wonder if it's possible to create 'that' without knowing the name of the
> object? Take the following example with ??? where I don't know what to set:
>
> var ob_a={id:"a"};
> var ob_b={id:"b"};
> var alertid=function(){var that=???;alert("id="+that.id);}
> ob_a.alertid=alertid;
> ob_b.alertid=alertid;
>
> I'm guessing that there's no way to define 'that' which would work for
> both objects there, and I'd have to define an anonymous function for
> each object, with hard-coded references to ob_a and ob_b in them like so:
>
> var ob_a={id:"a"};
> var ob_b={id:"b"};
> ob_a.alertid=function(){var that=ob_a;alert("id="+that.id);};
> ob_b.alertid=function(){var that=ob_b;alert("id="+that.id);}

var alertid = function(that){ alert("id=" + that.id); };
// ...
ob_a.alertid = function() { alertid(this); };
ob_b.alertid = function() { alertid(this); };

or

var alertid = function(){ alert("id=" + this.id); }
// ...

and then either

ob_a.alertid = function() { alertid.call(this); };
ob_b.alertid = function() { alertid.call(this); };

or

ob_a.alertid = function() { alertid.apply(this); };
ob_b.alertid = function() { alertid.apply(this); };


HTH

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

Thomas 'PointedEars' Lahn wrote:
> No, it can't be (other than parsing the source code somehow). Objects have
> no name, they have identity (two compared object "instances"[1] are either
> the same object or they are different objects). `ob' is but the identifier
> of only one possible reference of that object


I've figured out a way that's satisfactory even if not perfect:-

var ob_a={id:"a",funcs:[]};
ob_a.alertid=function(){alert("id="+this.id);}
ob_a.funcs[0]=ob_a.alertid;
ob_a.funcs.id=ob_a.id; // ### -- this is the key line -- ###
ob_a.alertid(); //works! this.id is actually ob_a.id
ob_a.funcs[0](); //works! this.id is actually ob_a.funcs.id

I copy the id property of the ob_a object into the funcs array object.
Doing that gives the funcs array the same value. I know it's not a
reference to this.id, instead it's a copy of it. That's sufficient though.

Having that id copy also enables me to create a dynamic that property in
the alertid function like this (if I want to). In this case all the
objects start with ob_ followed by what's in the id string. If that
wasn't the case, then I could just write the name of the variable as a
new property of the funcs array also :-

ob_a.alertid=function(){
var that=window["ob_"+this.id];
alert("id="+that.id); //this will now use ob_a.id
}

Thanks for the knowledge growth guys.

On Aug 8, 4:17 pm, RobG <rg... RemoveThis @iinet.net.au> wrote:
> On Aug 9, 7:23 am, Stevo <ple... RemoveThis @spam-me.com> wrote:
>
<..>
>
> I think the best post I've seen about the this keyword is the one here
> by Mike Winter:
>
> <URL:http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thr...
>
> The first part is about closures, the second part on this is
> excellent.
>

With regard to the second part only, and in spite of many excellent
posts that Mike contributed, this one doesn't quite make that rating
in my book.

The first problem is the use of the term "this operator" which, quite
remarkably, also seems to have found its way into Mozilla JS 1.5
documentation:

<URL:http://developer.mozilla.org/en/docs/
Core_JavaScript_1.5_Reference:Operators:Special_Operators:this_Operator>

"this" in Javascript is not an operator, it is a (read-only) variable
and can be used as any other variable operand of type
"object" (although, as it is read-only, it cannot be directly assigned
within the program).

"this" can implicitly given a value, with the most direct implicit
assignment being attained through the function.prototype.call/apply
methods. Nonetheless, in the most common usage, "this" takes it value
initially as a reference to the global object, and automatically
changes as execution contexts are created (and restored) for method
calls in accordance with the way in which the reference to the method
was designated.

If the reference to the method is obtained without use of dot or
bracket notation, "this" is assigned a reference to the global object.
On the other hand if dot or bracket notation is used to arrive at the
reference, "this" is assigned the object at the end of the accessor
path that leads to the reference.

In other words, a function invoked as f(...) will have a "this" value
of the global object, whereas a.b.c.f(...) would have a "this" value
of c.

Perhaps most non-intuitive in the above is that the above paragraph
applies even when an inner function is called, where one might expect
the "this" value to be preserved (as it is when code under the eval
function is invoked).

So the second problem with Mike's post is that it over-complicates the
description of what one should expect of the "this" value to be by
involving the variable object, scope chain and the "new" operator[1]
in the description.

See "Objects and this" at

<URL:http://javascript.crockford.com/survey.html>

for a much more succinct, easy to grasp, description.

[1] The new operator relationship to "this" is really just a special
case of function.prototype.call (performed internally) of the
constructor function.
--
../rh

On Aug 16, 3:50 pm, ron.h.h....TakeThisOut@gmail.com wrote:
<snip>
> In other words, a function invoked as f(...) will have a
> "this" value of the global object,

function f(){
var x = (this+'');
}

with(
{
f:f,
toString:function(){alert('I am not the global object');}
}
){
f(); // alerts: I am not the global object
// So the - this - value when - f() - is
// executed is _not_ the global object.
}

You appear to have failed to take into account the role of variable
objects and the scope chain in determining the - this - value.

<snip>
> So the second problem with Mike's post is that it over-complicates
> the description of what one should expect of the "this" value to
> be by involving the variable object, scope chain and the "new"
> operator[1] in the description.
<snip>

On Aug 16, 9:27 am, Henry <rcornf....RemoveThis@raindrop.co.uk> wrote:
> On Aug 16, 3:50 pm, ron.h.h....RemoveThis@gmail.com wrote:
> <snip>
>
> > In other words, a function invoked as f(...) will have a
> > "this" value of the global object,
>
> function f(){
> var x = (this+'');
>
> }
>
> with(
> {
> f:f,
> toString:function(){alert('I am not the global object');}
> }
> ){
> f(); // alerts: I am not the global object
> // So the - this - value when - f() - is
> // executed is _not_ the global object.
>
> }
>
> You appear to have failed to take into account the role of variable
> objects and the scope chain in determining the - this - value.
>

So, given the Michael Winter post under discussion, what would you say
the "The global and activation/variable objects:" section, that brings
under consideration scope chains, activation and variable objects,
leads to as the "this" value in your example?

"with", as always, is a special case (and that is part of the reason
that its use is generally recommended against). The relevance of the
scope chain in this case has to do with search order, and is
incidental to the setting of the "this" value on call to a method
found as a property of the "with" computed object.

Syntactically, you are correct, that explicit accessor processing does
not occur at the time of the call. Nonetheless, logically, the
property when found can be thought of as

withComputedObject[propertyName]

, and therefore the simple rule given for determination of the "this"
value under a call applies.

--
../rh

ron.h.hall DeleteThis @gmail.com wrote:
> The first problem is the use of the term "this operator" which, quite
> remarkably, also seems to have found its way into Mozilla JS 1.5
> documentation:
>
> <URL:http://developer.mozilla.org/en/docs/
> Core_JavaScript_1.5_Reference:Operators:Special_Operators:this_Operator>
>
> "this" in Javascript is not an operator, it is a (read-only) variable

It is neither. `this' is not defined as a property of a Variable Object of
an execution context. `this' is a reserved word, a keyword, and it can be
considered "a value" ([ES3], 10.2).

> [...]
> If the reference to the method is obtained without use of dot or
> bracket notation, "this" is assigned a reference to the global object.

That is over-simplifying the matter. `this' within a method refers to the
calling object ([ES3], 10.2.3). Not using an ObjectReference is having
identifier resolution to try the next object in the scope chain, which is
often, but not always, the Global Object ([ES3], 10.1.4). At least the
MSHTML DOM proves that there is another object in the scope chain before
the Global Object.

> On the other hand if dot or bracket notation is used to arrive at the
> reference, "this" is assigned the object at the end of the accessor
> path that leads to the reference.

That is over-complicating the matter. `this' within a method refers to the
calling object (see above).

> In other words, a function invoked as f(...) will have a "this" value
> of the global object, whereas a.b.c.f(...) would have a "this" value
> of c.

Globally declared functions are methods of the Global Object, as that is the
Variable Object of the global execution context ([ES3], 13). So the value
of the `this' value in that context is a reference to the Global Object.

Methods are function-type properties ([ES3], 4.3.3).

> [...]
> So the second problem with Mike's post is that it over-complicates the
> description of what one should expect of the "this" value to be by
> involving the variable object, scope chain and the "new" operator[1]
> in the description.

So far for over-complicating. Please read [ES3] before you post even more
of such half-truths.

[ES3]
http://developer.mozilla.org/en/docs/JavaScript_Language_Resources#Jav...ript_1.


PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>

On Aug 17, 12:50 am, ron.h.h....TakeThisOut@gmail.com wrote:
> On Aug 8, 4:17 pm, RobG <rg....TakeThisOut@iinet.net.au> wrote:
> > On Aug 9, 7:23 am, Stevo <ple....TakeThisOut@spam-me.com> wrote:
>
> <..>
>
> > I think the best post I've seen about the this keyword is the one here
> > by Mike Winter:
>
> > <URL:http://groups.google.com.au/group/comp.lang.javascript/browse_frm/thr...
>
> > The first part is about closures, the second part on this is
> > excellent.
>
> With regard to the second part only, and in spite of many excellent
> posts that Mike contributed, this one doesn't quite make that rating
> in my book.
>
> The first problem is the use of the term "this operator" which,

Mike explained in another post why he uses that term. I've spent some
time trying to find it but can't.

[...]
> If the reference to the method is obtained without use of dot or
> bracket notation, "this" is assigned a reference to the global object.
> On the other hand if dot or bracket notation is used to arrive at the
> reference, "this" is assigned the object at the end of the accessor
> path that leads to the reference.
>
> In other words, a function invoked as f(...) will have a "this" value
> of the global object, whereas a.b.c.f(...) would have a "this" value
> of c.
>
> Perhaps most non-intuitive in the above is that the above paragraph
> applies even when an inner function is called, where one might expect
> the "this" value to be preserved (as it is when code under the eval
> function is invoked).
>
> So the second problem with Mike's post is that it over-complicates the
> description of what one should expect of the "this" value to be by
> involving the variable object, scope chain and the "new" operator[1]
> in the description.

I think he's being thorough. His explanation regarding identifier
resolution explains how the this keyword of an inner function is a
reference to the global object, even if the this keyword of the outer
function is some other value.

e.g.

function foo(){
alert('foo: this == window : ' + !!(this == window));
function bar() {
alert('bar: this == window : ' + !!(this == window));
}
bar();
}
var x = {};
x.foo = foo;
x.foo(); // foo: this == window : false
// bar: this == window : true


When resolving the local variable bar, it is found on foo's variable
object and so its this keyword is set to the global object, even
though the outer function, foo, has its this keyword set to x.

If a programmer wants the inner function to have access to the outer
function's this keyword, they can do:

function foo(){
var fooThis = this;
function bar() {
// Use fooThis
}
bar();
}

or

function foo(){
function bar() {
// this = foo's this;
}
bar.call(this);
}


>
> See "Objects and this" at
>
> <URL:http://javascript.crockford.com/survey.html>
>
> for a much more succinct, easy to grasp, description.

It is a simple description that covers the majority of cases, but it
doesn't explain why. One reason I like Mike's explanations is that
they can be read and understood in conjunction with the ECMAScript
specification [1]. I don't think Douglas Crockford's can (which isn't
a criticism, I suspect that was never his intention).


1. Richard Cornford's posts fall into the same category, though they
are often much more difficult to understand.

--
Rob

On Aug 16, 7:53 pm, RobG <rg....TakeThisOut@iinet.net.au> wrote:
> On Aug 17, 12:50 am, ron.h.h....TakeThisOut@gmail.com wrote:
>
<...>
> > The first problem is the use of the term "this operator" which,
>
> Mike explained in another post why he uses that term. I've spent some
> time trying to find it but can't.
>
> [...]
>
It would be interesting to see that. The terminology used is contrary
to any standard definition of "operator" versus "variable", where, in
general terms, an operator invokes an action that creates a result,
and a variable provides storage for a result.

ECMAScript 262/3 does not list "this" as an operator (not to my
surprise, nor does it list it as a variable, because for the
specification it's not. Perhaps pseudo-variable would a better term).

>
> > So the second problem with Mike's post is that it over-complicates the
> > description of what one should expect of the "this" value to be by
> > involving the variable object, scope chain and the "new" operator[1]
> > in the description.
>
> I think he's being thorough. His explanation regarding identifier
> resolution explains how the this keyword of an inner function is a
> reference to the global object, even if the this keyword of the outer
> function is some other value.
>

And, as always, he deserves commendation for his thoroughness.
However, in many cases you need to know what more than why, especially
when the why is relatively complex.

> e.g.
>
> function foo(){
> alert('foo: this == window : ' + !!(this == window));
> function bar() {
> alert('bar: this == window : ' + !!(this == window));
> }
> bar();}
>
> var x = {};
> x.foo = foo;
> x.foo(); // foo: this == window : false
> // bar: this == window : true
>
Or, to preserve "this", the bar() can be changed to bar.call(this) -
just a touch more convoluted than one might expect.

> When resolving the local variable bar, it is found on foo's variable
> object and so its this keyword is set to the global object, even
> though the outer function, foo, has its this keyword set to x.
>

But why should I care when the rationale is nothing more than that's
what the specification says it will be, as long as I have a way of
knowing what it will be, or a way of setting it to what I want it to
be?

> If a programmer wants the inner function to have access to the outer
> function's this keyword, they can do:
>
> function foo(){
> var fooThis = this;
> function bar() {
> // Use fooThis
> }
> bar();
>
> }
>
> or
>
> function foo(){
> function bar() {
> // this = foo's this;
> }
> bar.call(this);
>
> }
>
> > See "Objects and this" at
>
> > <URL:http://javascript.crockford.com/survey.html>
>
> > for a much more succinct, easy to grasp, description.
>
> It is a simple description that covers the majority of cases, but it
> doesn't explain why. One reason I like Mike's explanations is that
> they can be read and understood in conjunction with the ECMAScript
> specification [1]. I don't think Douglas Crockford's can (which isn't
> a criticism, I suspect that was never his intention).
>
And that's to some extent a question of whether everyone who wishes to
program in JavaScript should have to read and be able to comprehend
the ECMAScript specification in order to be able to use the language
effectively.

Given the amount of confusion over "this", even by those who have a
fair degree of experience with the language, I prefer to see
something presented in abstract form that can be readily grasped
without the involvement of relatively complex internal specification,
at least where possible.

Even so, as the "this" value setting seems to violate the "Principle
of Least Astonishment" in some cases, a simple rule is as good as an
explanation from the specification, as there may be no more rationale
found there than in a rule.

<...>

--
../rh