Prev: writing a javascript client-side shopping cart
Next: comp.lang.javascript FAQ - April 1996
From: Eleandor on 26 Apr 2010 14:16
Hi, I'm currently facing an annoying problem with the this "pointer".

Here's an abstract version of the code I'm trying to write:

var Apple1 = null;
var Apple2 = new Apple();

function Apple() {
Apple1 = this;
this.eat = function() {
alert("Yummy!");
}
}

The problem I have is that Apple1 remains undefined. What I was
expecting is that "this" would point to the new Apple but apparently
it doesn't. As a result, Apple1 = undefined, and is not equal to
Apple2.

Right now the workaround I have is something like this:
var Apple1 = new Apple(); Apple1.init(Apple1); // where init simply
sets Apple1.self = the parameter passed to init. Clearly this is not a
good solution.

How can I solve this? I don't think it'll be easy to really avoid this.
From: Stefan Weiss on 26 Apr 2010 14:34
On 26/04/10 20:16, Eleandor wrote:
> Hi, I'm currently facing an annoying problem with the this "pointer".

"reference"

> Here's an abstract version of the code I'm trying to write:
>
> var Apple1 = null;
> var Apple2 = new Apple();
>
> function Apple() {
> Apple1 = this;
> this.eat = function() {
> alert("Yummy!");
> }
> }
>
> The problem I have is that Apple1 remains undefined. What I was
> expecting is that "this" would point to the new Apple but apparently
> it doesn't. As a result, Apple1 = undefined, and is not equal to
> Apple2.

Maybe you should show us the real version, instead of the "abstract"
one. The way you posted it, Apple1 and Apple2 will in fact refer to the
same object, and Apple1.eat() will alert "Yummy!".

Even if the "Apple1 = this" assignment didn't work, Apple1 would not be
undefined, because you assigned null to it (null !== undefined).

> Right now the workaround I have is something like this:
> var Apple1 = new Apple(); Apple1.init(Apple1); // where init simply
> sets Apple1.self = the parameter passed to init. Clearly this is not a
> good solution.
>
> How can I solve this? I don't think it'll be easy to really avoid this.

I have no idea what you're actually trying to do. The whole thing
doesn't look right; why do you think you need it?


--
stefan
From: Eleandor on 27 Apr 2010 08:05
Apparently I must have made another mistake somewhere since it's now
working like it should. I've had this problem occur more than once
(otherwise I wouldn't really post a help message) so I'm pretty
puzzled as to what went wrong. But it's fixed now...

Thank you for your help anyway.
From: BGB / cr88192 on 27 Apr 2010 21:02

"Eleandor" <vanbeurden.bart(a)gmail.com> wrote in message
news:5c4fa31e-db2c-49bf-b663-8dd1d825d95c(a)y14g2000yqm.googlegroups.com...
> Apparently I must have made another mistake somewhere since it's now
> working like it should. I've had this problem occur more than once
> (otherwise I wouldn't really post a help message) so I'm pretty
> puzzled as to what went wrong. But it's fixed now...
>

although I am not really an expert on JavaScript in general, a possible
issue may be that some assumptions are being made regarding the semantics of
"this" (in the context of "new"), that might not be the case (such as
assuming that "this" behaves the same as other variables, that "this"
necessarily references a valid object within the constructor, ...). I am not
sure if these assumptions are (necessarily) required by an implementation.


for example, "this" is typically handled as a keyword, which could easily
generate special opcodes or similar (rather than attempt to look up some
object and perform operations on it).

similarly, it seems reasonable that "this" could be given different
semantics within a constructor, essentially delaying creation of the object
until after the "new" operation has finished. for example, this could be
used for performance reasons on an implementation built on top of a
Class/Instance object system, for example, since it would help establish a
signature for the object prior to initial creation (dynamic modification
could end up doing something like recreating the object with a new class and
copying its contents, which would be expensive, but at the tradeoff that
overall performance and memory use would be better in the common case of
objects which don't change their physical representation).


a lot of this would likely depend on the particular implementation though.


> Thank you for your help anyway.


From: Stefan Weiss on 28 Apr 2010 03:21
On 28/04/10 03:02, BGB / cr88192 wrote:
> although I am not really an expert on JavaScript in general, a possible
> issue may be that some assumptions are being made regarding the semantics of
> "this" (in the context of "new"), that might not be the case (such as
> assuming that "this" behaves the same as other variables, that "this"
> necessarily references a valid object within the constructor, ...). I am not
> sure if these assumptions are (necessarily) required by an implementation.

"this" is always an object. It never behaves like a variable, because it
is immutable. And yes, that's required of a conforming implementation;
see 10.1.7 and 10.2 in ECMA-262.

> similarly, it seems reasonable that "this" could be given different
> semantics within a constructor, essentially delaying creation of the object
> until after the "new" operation has finished.

It may seem reasonable, but it's not what happens. "this" is available
and will point to the appropriate object right from the start - it is
created when "entering an execution context".

I can't say what the original problem was. One possibility is that the
Apple constructor was called as a function, not as a constructor:

function Apple () {
// in this example, "this" is not an Apple, but the global object,
// and "eat" will become a global function
this.eat = function () {
alert("yummy!");
};
}

var apple1 = Apple(); // (no "new")
eat(); // "yummy!"
apple1.eat(); // error, apple1 is undefined


--
stefan
 |  Next  |  Last
Pages: 1 2
Prev: writing a javascript client-side shopping cart
Next: comp.lang.javascript FAQ - April 1996