Self Pointer?

E

Eleandor

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.
 
E

Eleandor

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.
 
B

BGB / cr88192

Eleandor said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top