Yeah, basically. A privileged method can access private members, whereas, in more regular languages, public methods can’t really do that.

I can’t see any difference in the syntax for a privileged method and a public method (when not using prototype) so… is a method called public/privileged based on the variables it access?

Thanks in advance

JT.

Glad that you liked it!

Thanks!!

Well, they’re shared by instances, so-to-say, but not by prototype methods, and that’s what Adam was aiming for.

Also, good posting the link, it’s good to have in this context!

Kind Regards

I think I will write one, in some form at least.

Ah, I see what you mean. That does indeed work.
The problem with it, however, is that the prototype for MyClass becomes an anonymously created object, where you declare the public method getPrivate inline in the constructor, instead of using a prototype.

I.e. each instance would have to create its own getPrivate method, instead of using the one inherited down through the prototype chain.

Can you not do the following:


var MyClass = function() {
}
MyClass.prototype = new(function(){
var privateVar = 1;

this.getPrivate = getPrivate;
});
var myInstance = new MyClass();
alert(myInstance.getPrivate()); // this alerts 1


I just tested and it seemed to work.

Interesting thinking!
The problem, however, with that approach is that you can’t access that private variable in any other method for the object. I.e., this won’t work:


MyClass.prototype.getPrivate = function(){
return myPrivateMember;
};

With Andrea’s solution above, it is possible with private variables accessible to all methods, as long as they’re declared within the closure, but outside the constructor.

Maybe I should write a post explaining what Andrea touched on above, with private members, to have it more easy to overview than in the comments.

With regards to using private methods and variable on the prototype, I believe you can do the following:

var MyClass = function() {
}

MyClass.prototype = new (function(){
this.myPublicMember = "public";
var myPrivateMember = "private";
});


I would love to see a post on using the prototype in much more detail.

Thanks

Yeah, exactly my thinking.

Thank you! It passed my mind while writing to Andrew, but naturally, a closure with the constructor (and returning the constructor as well) together with private members is a possible approach.

The only downside, structure-wise, from that is that you can’t define anything private in the actual constructor, and access from somewhere else.

Anyway, as Robert said, for the private variable usable via instance we need privileged methods, specially since Mozilla removed the second argument from eval function

Finally, with a dedicated closure it is possible to define prototypes that use private methods, always in that scope, so privileged method are usually not necessary at all


function Person(name){
this.name = name;
};

Person.prototype.getName = function(){
return _getName.call(this);
};
})();

Of course the constructor could be inside the closure as well, something like:

Person = (function(){ // closure for everything
function Person(){};
Person.prototype.dostuff = function(){ ... };
return Person;
})();

just to preserve the Function.prototype.name behaviour, where in Person case will be “Person” instead of an empty string

Thank you!
It’s a very good question, and something I’ve pondered too. Most of the time, I don’t even use prototypical inheritance, but instead work with the Yahoo JavaScript Module Pattern and good namespacing.

But, while typing this at least, if you go the prototype route (which you should, if you need proper inheritance), you need to use privileged or public methods in the constructor to achieve this.

I have a question: is there a way of having private members that are accesible by public functions created as a prototype? In C++, which is the language I learned Object Orientation in, anything that didn’t need to be public was private. In JavaScript, if you use the prototype avenue, you’re forced to make members public to allow for them to be accessed by public methods.

Let’s say we have the following code:

function YourConstructor() {
var blah = 0;
}

and the following method:

YourConstructor.prototype.getSomething = function () {
return blah;
}

Obviously, instantiating the class as an object and then calling getSomething() isn’t going to work. Because of this, I find myself making members public that don’t need to be, and that doesn’t make a ton of sense from the perspective of OOP. Obviously we have the advantage of a dynamic scope via the this keyword, but other than that, Class methods are really no more effective than regular functions that simply sift through public object members. Am I doing something wrong?

Thank you!
And you’re absolutely right, and it’s what Andrea pointed out as well. My public method code here was more for clarity than best practice, so I’ve updated the article with a correction about using prototype.

Glad that you like the JavaScript articles! With the inheritance and the scope and closures articles, together with this one, I think there won’t be too many in the near future, but one never knows.

It all comes down to inspiration and what lines of thoughts I meet daily.