Is there any way to make “private” variables (those defined in the constructor), available to prototype-defined methods?
TestClass = function(){
var privateField = "hello";
this.nonProtoHello = function(){alert(privateField)};
};
TestClass.prototype.prototypeHello = function(){alert(privateField)};
This works:
t.nonProtoHello()
But this doesn’t:
t.prototypeHello()
I’m used to defining my methods inside the constructor, but am moving away from that for a couple reasons.
There is a very simple way to do this
JavaScript prototypes are golden.
How's this? Using an private accessor. Only allows you to get the variables though not to set them, depends on the use case.
When I read this, it sounded like a tough challenge so I decided to figure out a way. What I came up with was CRAAAAZY but it totally works.
First, I tried defining the class in an immediate function so you'd have access to some of the private properties of that function. This works and allows you to get some private data, however, if you try to set the private data you'll soon find that all the objects will share the same value.
There are plenty of cases where this would be adequate like if you wanted to have constant values like event names that get shared between instances. But essentially, they act like private static variables.
If you absolutely need access to variables in a private namespace from within your methods defined on the prototype, you can try this pattern.
I'd love some feedback from anyone who sees an error with this way of doing it.
Here's what I came up with.
the main problem with this implementation is that it redefines the prototypes on every instanciation.
Was playing around with this today and this was the only solution I could find without using Symbols. Best thing about this is it can actually all be completely private.
The solution is based around a homegrown module loader which basically becomes the mediator for a private storage cache (using a weak map).
I suggest it would probably be a good idea to describe "having a prototype assignment in a constructor" as a Javascript anti-pattern. Think about it. It is way too risky.
What you're actually doing there on creation of the second object (i.e. b) is redefining that prototype function for all objects that use that prototype. This will effectively reset the value for object a in your example. It will work if you want a shared variable and if you happen to create all of the object instances up front, but it feels way too risky.
I found a bug in some Javascript I was working on recently that was due to this exact anti-pattern. It was trying to set a drag and drop handler on the particular object being created but was instead doing it for all instances. Not good.
Doug Crockford's solution is the best.