How to access private variables directly from privilged function?

[Rob Long]

Hi there

Is there any way to access private variables directly from within a
priviliged function? I have a situation where the priviliged function's
execution context contains variables of the same name as the parent
context, but I want direct access to the parent context's variable.

E.g. I would like to be able to do this...

function Point()
{
var x = 0;
var y = 0;

this.setX(x)
{
// set private x with local x
}

this.setY(y)
{
// set private y with local y
}
}

I can obviously do this with

function Point()
{
var x = 0;
var y = 0;

this.setX(xLocal)
{
x = xLocal;
}

this.setY(yLocal)
{
y = yLocal;
}
}

But is there a way that avoids having to check for naming conflicts all
the time? I guess setX and setY will be assigned an execution context
and scope chain, but I need a way to access the scope chain one level
up, a bit like the "prototype" keyword can for "class" scope chains.
Problem is that "x" is being found in the first level so the next level
up is never checked. I'm no guru so I might be confusing things here,
but if I could do something *similar* to

this.setX(x)
{
prototype.x = x;
}

then I would be a very happy man... Cos in java I'm used to doing

void setX(int x)
{
this.x = x;
}

Thanks in advance!

 

[Thomas 'PointedEars' Lahn]

Is there any way to access private variables directly from within a
priviliged function? I have a situation where the priviliged function's
execution context contains variables of the same name as the parent
context, but I want direct access to the parent context's variable.
[...]
I can obviously do this with

function Point()
{
var x = 0;
var y = 0;

this.setX(xLocal)
{
x = xLocal;
}

this.setY(yLocal)
{
y = yLocal;
}
}

But is there a way that avoids having to check for naming conflicts all
the time? I guess setX and setY will be assigned an execution context
and scope chain, but I need a way to access the scope chain one level
up, a bit like the "prototype" keyword can for "class" scope chains.

The prototype object of a constructor is accessed through the prototype
chain, not through the scope chain. And there are no classes there, but
maybe you were already aware of that.

Problem is that "x" is being found in the first level so the next level
up is never checked. I'm no guru so I might be confusing things here,
but if I could do something *similar* to

this.setX(x)
{
prototype.x = x;
}

then I would be a very happy man... Cos in java I'm used to doing

void setX(int x)
{
this.x = x;
}

Since implementations of ECMAScript Ed. 1 to 3 have no built-in concept of
information hiding as Java has, and you cannot refer to the Variable Object
of an execution context (of which the variables declared for that context
are properties), it is not be possible to avoid those naming conflicts
other than

A) making sure the named argument has a name different than
one of the local variable of the superordered context,

B) not naming the arguments and using the `arguments' object instead

C) using (public) properties instead of local variables,

D) using an implementation of ECMAScript Edition 4 instead.

Unfortunately, there is no client-side production-level implementation of
ECMAScript Ed. 4 yet, most certainly because this edition is itself still
only a working draft proposed to the ECMA WG about four years ago.

So, I am afraid probably you will have to end up with something like

function Point(x, y)
{
this.setX(x);
this.setY(y);
}

Point.prototype = {
constructor: Point,

setX: function(x)
{
this.x = x || 0;
}

setY: function(y)
{
this.y = y || 0;
}
};

thereby sacrificing the "private" visibility property of the identifiers,
unless this is to work server-side (in which case you could use JScript.NET
and its implementation of ECMAScript Ed. 4 classes). Of course you could
also define setters and getters, but those are JavaScript 1.5+ only, so not
interoperable (IE, for example, supports JScript).


HTH

PointedEars

 

[Rob Long]

Thanks very much for your help, Thomas.

I had a feeling that would be the case. It's actually not too much of a
problem, more of a nice-to-have. I'm going to go with suggestions A and
C - avoid the naming conflicts and make the variables public (using a
convention for private and protected members).

I realised after my first post that using the private and privileges
functions in that way doesn't fit with the inhertiance model I'm using
either, so that makes it all academic.

As a side, and if you have time, could you take a look at the current
way I'm using JS to achieve OO features such as classes, inhertiance
and polymorphism? I'd appreciate your comments/thoughts on how I've
done things. I've included a (short) example web page here:

http://dev.kuluvalley.com/js/oo_example.html

Conventions I've used:

- private members prefixed with __ (double underscore)
- protected members prefixed with _ (single underscore)
- public members have no prefix
- my constructor functions (not js ones but oo-simulated ones) are
named __construct and are called last in the (js) constructor (sorry a
bit confusing with the terminology)

To simulate overriding/access to superclass functions I'm using a local
variable, __super, in each class as a holding place for a skeleton
object of the superclass whose (superclass) functions I call whilst
applying the current object as the execution context for the call.

I've found that using these tricks I can simulate all the OO features I
need without having to worry about prototype chains. Oh, and I don't
have the need to add members to my objects at runtime.

Thanks!
Rob