inherited private variables

[PragueExpat]

I (think) that I've come up with a pattern that I haven't seen in any
publications so far and I would like some feedback. Basically, I was
looking for a way to inherit private functions and I came up with
this:

//base private object constructor

function priv(){
this.a = 1;
this.b = 2;
}

//private object constructor that inherits from base private object

function priv2(){
this.c = 3;
this.d = 4;
}
priv2.prototype = new priv();

//constructor that uses private object in private namespace

function ob(){
var _ = new priv2();
return {
go:function(){
alert(_.a);
}
}
}

var test = new ob();

//returns 1

test.go();

//only go() is public

test;

-------------------------------------------

First of all, is this a known pattern? If so, sorry for the redundant
information. If not, are there any drawbacks that you can see? The
advantage, as I see it, is that inherited objects can also inherit
private functions and properties for use.

Any comments would be welcome.

[Dan Rumney]

Re: inherited private variables

PragueExpat wrote:

I (think) that I've come up with a pattern that I haven't seen in any
publications so far and I would like some feedback. Basically, I was
looking for a way to inherit private functions and I came up with
this:
>
//base private object constructor
>
function priv(){
this.a = 1;
this.b = 2;
}
>

[snip]

a and b are not private variables here. They are members of the object
so the are public to anyone with access to that object.

As a result, the rest of your pattern doesn't really show anything as
you don't have any private members in your code at all (except, perhaps
'_', but that is private in your final object, so accessing it is not a
big achievement.

[PragueExpat]

Re: inherited private variables

On Jun 9, 9:12 pm, Dan Rumney <danrum...@warp mail.netwrote:

PragueExpat wrote:

I (think) that I've come up with a pattern that I haven't seen in any
publications so far and I would like some feedback. Basically, I was
looking for a way to inherit private functions and I came up with
this:

>

//base private object constructor

>

function priv(){
this.a = 1;
this.b = 2;
}

>
[snip]
>
a and b are not private variables here. They are members of the object
so the are public to anyone with access to that object.
>
As a result, the rest of your pattern doesn't really show anything as
you don't have any private members in your code at all (except, perhaps
'_', but that is private in your final object, so accessing it is not a
big achievement.

I'm not so sure. The constructors priv and priv2 are not used to
create any public objects. The are used to create exactly one object
( _ ), which is private to the object 'test'. If you can see a way to
access a, b, c or d from outside of a privileged method in the
function ob, please show me how.

[Joost Diepenmaat]

Re: inherited private variables

PragueExpat <richhensel@gma il.comwrites:

I'm not so sure. The constructors priv and priv2 are not used to
create any public objects. The are used to create exactly one object
( _ ), which is private to the object 'test'. If you can see a way to
access a, b, c or d from outside of a privileged method in the
function ob, please show me how.

priv2.prototype .a

priv2.prototype .b

Ofcourse, you *could* delete priv2.prototype after instantiating all
the priv2 objects you need.

The only sane way to get really private properties in javascript is to
not use properties at all and use closures instead. But that's hardly
news.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Dan Rumney]

Re: inherited private variables

PragueExpat wrote:
[snip]

>>
>a and b are not private variables here. They are members of the object
>so the are public to anyone with access to that object.
>>
>As a result, the rest of your pattern doesn't really show anything as
>you don't have any private members in your code at all (except, perhaps
>'_', but that is private in your final object, so accessing it is not a
>big achievement.

>
>
I'm not so sure. The constructors priv and priv2 are not used to
create any public objects. The are used to create exactly one object
( _ ), which is private to the object 'test'. If you can see a way to
access a, b, c or d from outside of a privileged method in the
function ob, please show me how.

My point was that you didn't inherit any private functions.

You created an object with a private member which was a priv2 object.
This object had publicly available members a,b,c and d.

However, I now understand what you're getting at.

Take a look at:

http://crockford.com/javascript/private.html

It talks about accessing an object's private members from a public method.

[PragueExpat]

Re: inherited private variables

On Jun 9, 9:35 pm, Joost Diepenmaat <jo...@zeekat.n lwrote:

PragueExpat <richhen...@gma il.comwrites:

I'm not so sure. The constructors priv and priv2 are not used to
create any public objects. The are used to create exactly one object
( _ ), which is private to the object 'test'. If you can see a way to
access a, b, c or d from outside of a privileged method in the
function ob, please show me how.

>
priv2.prototype .a
>
priv2.prototype .b
>
Ofcourse, you *could* delete priv2.prototype after instantiating all
the priv2 objects you need.
>
The only sane way to get really private properties in javascript is to
not use properties at all and use closures instead. But that's hardly
news.
>
--
Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

Yes, you can call the .prototype (not IE, of course) but that only
gives the original value - my goal is to share and update private
information among inherited 'classes'. If a method in priv changed
property 'a' to 2, then there is no way to access that value, because
closures are being used.

Because the private variable ( _ ) is an object, you can change its
properties via private or privileged methods and they cannot be
accessed.

You could also use private functions in the constructor ob like this:

function ob(){
var _ = new priv2();
var times = function(){_.c * 2);
return {
go:function(){
alert(_.a);
}
}

}


Thoughts?

[PragueExpat]

Re: inherited private variables

On Jun 9, 10:09 pm, Dan Rumney <danrum...@warp mail.netwrote:

PragueExpat wrote:
>
[snip]
>
>
>

a and b are not private variables here. They are members of the object
so the are public to anyone with access to that object.

>

As a result, the rest of your pattern doesn't really show anything as
you don't have any private members in your code at all (except, perhaps
'_', but that is private in your final object, so accessing it is not a
big achievement.

>

I'm not so sure. The constructors priv and priv2 are not used to
create any public objects. The are used to create exactly one object
( _ ), which is private to the object 'test'. If you can see a way to
access a, b, c or d from outside of a privileged method in the
function ob, please show me how.

>
My point was that you didn't inherit any private functions.
>
You created an object with a private member which was a priv2 object.
This object had publicly available members a,b,c and d.
>
However, I now understand what you're getting at.
>
Take a look at:http://crockford.com/javascript/private.html
>
It talks about accessing an object's private members from a public method.

Yes, you are correct that I didn't inherit private function - I
probably should have titled this thread something else. I'm just
really curious to see if this is a way to inherit properties/methods
that cannot be accessed from outside privileged methods. The reason
for this idea was because it is difficult to inherit objects that have
private functions and I was looking for a way to do that.

I'm still not sure that its viable but I'm not yet convinced that its
not.

[Joost Diepenmaat]

Re: inherited private variables

PragueExpat <richhensel@gma il.comwrites:

Yes, you can call the .prototype (not IE, of course)

You mean "also in IE, of course". I hope. This is fully supported and
standardized behaviour.

but that only gives the original value - my goal is to share and
update private information among inherited 'classes'. If a method in
priv changed property 'a' to 2, then there is no way to access that
value, because closures are being used.

That's because if you set the property, you're not inheriting it
anymore.

See section "property lookup" in

http://joost.zeekat.nl/constructors-considered-mildly-confusing.html

Because the private variable ( _ ) is an object, you can change its
properties via private or privileged methods and they cannot be
accessed.

Yes, that's because it's a local variable, captured by a closure, and
you *can* create "truely private" "properties " using closures. But
none of that has anything to do with inheritance, or properties,
really. Just because you're closing over an object that uses
inheritance doesn't mean the inheritance chain and its properties are
now somehow private. It just means you're making that one object
private.

You could also use private functions in the constructor ob like this:
>
function ob(){
var _ = new priv2();
var times = function(){_.c * 2);
return {
go:function(){
alert(_.a);
}
}
>
}

I know. :-)

Thoughts?

I still don't see how inheritance comes in to this. Maybe my mind is
slow today, but I think you're ascribing more functionality to the
code than is actually shown.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[PragueExpat]

Re: inherited private variables

First of all, thanks for the feedback - very interesting

On Jun 9, 10:25 pm, Joost Diepenmaat <jo...@zeekat.n lwrote:

PragueExpat <richhen...@gma il.comwrites:

Yes, you can call the .prototype (not IE, of course)

>
You mean "also in IE, of course". I hope. This is fully supported and
standardized behaviour.
>

you can call object.prototyp e in IE? I'm fairly sure that IE doesn't
support that (I'm not talking about setting a function's prototype,
but rather getting the prototype of an existing object)

function a(){

}
a.prototype={
b:1
}

calling a.prototype in IE will come back with undefined

but that only gives the original value - my goal is to share and
update private information among inherited 'classes'. If a method in
priv changed property 'a' to 2, then there is no way to access that
value, because closures are being used.

>
That's because if you set the property, you're not inheriting it
anymore.

Yes, I see what you're saying -I'm not trying so much to inherit
static properties, but also private functions. And by private
functions, maybe I'm using that in the wrong sense - I mean functions
that cannot be accessed on an object except through privileged
methods.

>
See section "property lookup" inhttp://joost.zeekat.nl/constructors-considered-mildly-confusing.html
>

Because the private variable ( _ ) is an object, you can change its
properties via private or privileged methods and they cannot be
accessed.

>
Yes, that's because it's a local variable, captured by a closure, and
you *can* create "truely private" "properties " using closures. But
none of that has anything to do with inheritance, or properties,
really. Just because you're closing over an object that uses
inheritance doesn't mean the inheritance chain and its properties are
now somehow private. It just means you're making that one object
private.

OK, that makes sense.

>

You could also use private functions in the constructor ob like this:

>

function ob(){
var _ = new priv2();
var times = function(){_.c * 2);
return {
go:function(){
alert(_.a);
}
}

>

}

>
I know. :-)
>

Thoughts?

>
I still don't see how inheritance comes in to this. Maybe my mind is
slow today, but I think you're ascribing more functionality to the
code than is actually shown.
>

I thought of this pattern because normally I do this:

var x = function(){

//private
var a = function...
var b = function...

return {
c:function...
d:function...
}

and reusing the private functions in an inherited object is not
possible. I was trying to find a way that an inherited object could
also get access to the private functions for use.


}

--
Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

[Joost Diepenmaat]

Re: inherited private variables

PragueExpat <richhensel@gma il.comwrites:

First of all, thanks for the feedback - very interesting
>
On Jun 9, 10:25 pm, Joost Diepenmaat <jo...@zeekat.n lwrote:

>PragueExpat <richhen...@gma il.comwrites:

Yes, you can call the .prototype (not IE, of course)

>>
>You mean "also in IE, of course". I hope. This is fully supported and
>standardized behaviour.
>>

>
you can call object.prototyp e in IE? I'm fairly sure that IE doesn't
support that (I'm not talking about setting a function's prototype,
but rather getting the prototype of an existing object)

*I was* talking about getting a function's prototype property. Not an
object's "hidden" prototype.

function a(){
>
}
a.prototype={
b:1
}
>
calling a.prototype in IE will come back with undefined

No it won't. You really should test that.

< snip >

>I still don't see how inheritance comes in to this. Maybe my mind is
>slow today, but I think you're ascribing more functionality to the
>code than is actually shown.
>>

>
I thought of this pattern because normally I do this:
>
var x = function(){
>
//private
var a = function...
var b = function...
>
return {
c:function...
d:function...
}
>
and reusing the private functions in an inherited object is not
possible. I was trying to find a way that an inherited object could
also get access to the private functions for use.

The only way to do that, that I can see, is to define the relevant
methods of the inheriting object in the same scope as the var a etc
functions here - in other words, close over the the functions in the
"sub" object. Any other way will just move the problem around (or make
the properties "public" again).

Closures are orthogonal to the whole object mechanism in javascript,
which is why they provide such good isolation, but that also means you
can't really get (at) private variables via the standard
inheritance/prototyping mechanism. (but it's possible to build objects
and inheritance out of closures and work the other way around, if you
think javascript isn't slow and verbose enough).

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[PragueExpat]

Re: inherited private variables

On Jun 9, 11:14 pm, Joost Diepenmaat <jo...@zeekat.n lwrote:

PragueExpat <richhen...@gma il.comwrites:

First of all, thanks for the feedback - very interesting

>

On Jun 9, 10:25 pm, Joost Diepenmaat <jo...@zeekat.n lwrote:

PragueExpat <richhen...@gma il.comwrites:
Yes, you can call the .prototype (not IE, of course)

>

You mean "also in IE, of course". I hope. This is fully supported and
standardized behaviour.

>

you can call object.prototyp e in IE? I'm fairly sure that IE doesn't
support that (I'm not talking about setting a function's prototype,
but rather getting the prototype of an existing object)

>
*I was* talking about getting a function's prototype property. Not an
object's "hidden" prototype.
>

function a(){

>

}
a.prototype={
b:1
}

>

calling a.prototype in IE will come back with undefined

>
No it won't. You really should test that.

You are right - I stand corrected :)

>
< snip >
>
>
>

I still don't see how inheritance comes in to this. Maybe my mind is
slow today, but I think you're ascribing more functionality to the
code than is actually shown.

>

I thought of this pattern because normally I do this:

>

var x = function(){

>

//private
var a = function...
var b = function...

>

return {
c:function...
d:function...
}

>

and reusing the private functions in an inherited object is not
possible. I was trying to find a way that an inherited object could
also get access to the private functions for use.

>
The only way to do that, that I can see, is to define the relevant
methods of the inheriting object in the same scope as the var a etc
functions here - in other words, close over the the functions in the
"sub" object. Any other way will just move the problem around (or make
the properties "public" again).
>
Closures are orthogonal to the whole object mechanism in javascript,
which is why they provide such good isolation, but that also means you
can't really get (at) private variables via the standard
inheritance/prototyping mechanism. (but it's possible to build objects
and inheritance out of closures and work the other way around, if you
think javascript isn't slow and verbose enough).
>
--
Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

Even if the constructors priv and priv2 have public members, the
resulting object is assigned to a private variable so in effect, the
result is what I was looking for: an object of variables/methods that
cannot be accessed except for the privileged methods. And I can reuse
or extend that object in the private scope of another object.

and if my constructor ob looked like this:

function ob(){
var _ = new priv2();
return {
init:function() {
_.that = this;
}
go:function(){
alert(_.a);
}
}

}

the private variable _ would have a pointer to the public object
properties

Don't you think that there is some value in that?

[Joost Diepenmaat]

Re: inherited private variables

PragueExpat <richhensel@gma il.comwrites:

Even if the constructors priv and priv2 have public members, the
resulting object is assigned to a private variable so in effect, the
result is what I was looking for: an object of variables/methods that
cannot be accessed except for the privileged methods. And I can reuse
or extend that object in the private scope of another object.
>
and if my constructor ob looked like this:
>
function ob(){
var _ = new priv2();
return {
init:function() {
_.that = this;
}
go:function(){
alert(_.a);
}
}
>
}
>
the private variable _ would have a pointer to the public object
properties
>
Don't you think that there is some value in that?

To be honest, I can see only very limited real uses for this kind of
construct, as far as it relates to inheritance, OO programming and
"protection " in javascript.

I like closures and functional programming just fine, but especially
in JS, where methods are mutable properties, I don't really see the
point of using closures to emulate private variables - you still need
a mutable method to get at them. AFAICT they're probably much more
useful to emulate class variables. IOW, I think closures definitely
have their place, but just using them for access control is missing
several points:

1. Closures are a lot more useful than that.

2. You don't want to control access, you just want to prevent name
collisions for truely private variables, so you can use _ or i or x
without overwriting some other function's _, i or x. Sane languages
already do this when you use (lexical or even dynamic) variables.

2. Object property/method access control is overrated:

*in general... (not aimed at you or anyone else in particular):*

As far as I can see, the public/private/protected attributes of
properties in most languages and most systems are just documentation
markers. They shouldn't be taken (or written) as infallible
protection; they just indicate the currently projected use of an API;
if you can't switch some property or method from private to public
when needed, you should probably make it public from the start (mark
it as private or unsupported in the documentation, choose a better
property/method name while you're at it).

And whoever thought up "protected" had better be damn sorry.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[PragueExpat]

Re: inherited private variables

On Jun 10, 12:13 am, Joost Diepenmaat <jo...@zeekat.n lwrote:

PragueExpat <richhen...@gma il.comwrites:

Even if the constructors priv and priv2 have public members, the
resulting object is assigned to a private variable so in effect, the
result is what I was looking for: an object of variables/methods that
cannot be accessed except for the privileged methods. And I can reuse
or extend that object in the private scope of another object.

>

and if my constructor ob looked like this:

>

function ob(){
var _ = new priv2();
return {
init:function() {
_.that = this;
}
go:function(){
alert(_.a);
}
}

>

}

>

the private variable _ would have a pointer to the public object
properties

>

Don't you think that there is some value in that?

>
To be honest, I can see only very limited real uses for this kind of
construct, as far as it relates to inheritance, OO programming and
"protection " in javascript.
>
I like closures and functional programming just fine, but especially
in JS, where methods are mutable properties, I don't really see the
point of using closures to emulate private variables - you still need
a mutable method to get at them. AFAICT they're probably much more
useful to emulate class variables. IOW, I think closures definitely
have their place, but just using them for access control is missing
several points:
>
1. Closures are a lot more useful than that.
>
2. You don't want to control access, you just want to prevent name
collisions for truely private variables, so you can use _ or i or x
without overwriting some other function's _, i or x. Sane languages
already do this when you use (lexical or even dynamic) variables.
>
2. Object property/method access control is overrated:
>
*in general... (not aimed at you or anyone else in particular):*
>
As far as I can see, the public/private/protected attributes of
properties in most languages and most systems are just documentation
markers. They shouldn't be taken (or written) as infallible
protection; they just indicate the currently projected use of an API;
if you can't switch some property or method from private to public
when needed, you should probably make it public from the start (mark
it as private or unsupported in the documentation, choose a better
property/method name while you're at it).
>
And whoever thought up "protected" had better be damn sorry.
>
--
Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/

Thanks again, Joost, for your insight. I appreciate the time you took
to talk about this.

[RoLo]

Re: inherited private variables

*in general... (not aimed at you or anyone else in particular):*

>
As far as I can see, the public/private/protected attributes of
properties in most languages and most systems are just documentation
markers. They shouldn't be taken (or written) as infallible
protection; they just indicate the currently projected use of an API;
if you can't switch some property or method from private to public
when needed, you should probably make it public from the start (mark
it as private or unsupported in the documentation, choose a better
property/method name while you're at it).
>
And whoever thought up "protected" had better be damn sorry.

Totally agree, public, private and protected definitions should be
used for organizing the code not for "securing" it... at least for
most languages. In JS, on the other hand I can imagine a couple of
situations where it could be used for a bit of "security".