Question

I want to implement setter and getter on local
javascript variable. Here is an example function:

function someThing() {
   var someLocalvariable = '';
}

// with this function I want to 
// return value of someLocalvariable
// also if it is possible to implement
// setter in this way. 
someThing.prototype.getLocalVar = function() {

}

I want variable to be ‘realy’ private. I don’t wont
to use something like this:
someThing.prototype.someLocalvariable =

or

function someThing() {
   this.someLocalvariable = '';
}

or attaching function inside someThing() like this:

function someThing() {
      var someLocalvariable = '';
   this.getLocalvariable = function() {
      return someLocalvariable;
   }
}

I would be very grateful for any guidance and assistance.

Answer 1

Your last example of what you don’t want to do won’t work (it has syntax errors), (it’s been fixed) but I think you may have meant the usual way of doing this, which is to make the getter and setter closures within the constructor function (below).

Unfortunately, if you want truly private variables, this is just about your only option. There is no other way to get truly private, instance-specific variables. However, see “hack” below.

Here’s the correct version of the usual way of doing this (which I think you said you don’t want, but for completeness):

function SomeThing() {
    var privateVar;

    this.setPrivateVar = function(val) {
        privateVar = val;
    };
    this.getPrivateVar = function() {
        return privateVar;
    };
}

// use:
var t = new Something();
t.setPrivateVar("foo");
console.log(t.getPrivateVar()); // "foo"

Like most, I first read of this pattern on Douglas Crockford’s site.

This option does carry a downside: Every instance created via the SomeThing constructor function gets its own two functions. They cannot be shared between instances. So if there are going to be hundreds or thousands of SomeThing instances in your app, that’s something to be considered from a memory perspective. If there are going to be a couple of hundred or fewer, it probably doesn’t matter. (Those numbers are pulled out of a hat and you should not trust them, you’ll have to review your code’s memory use when/if there’s some kind of issue; but you get the idea.)

The hack: If your instances will already have some kind of unique identifier on them as public data (or you’re willing to add one, again it will be public), and if you’re willing to add a fair bit of complication into the use of the instances, you can have a private cache that holds the data for all of your instances that only your code can access, and key into that cache via the unique identifier of the object. Like this (in this example, I’m allocating the id values, but you can use existing unique IDs if you have them):

var SomeThing = (function() {
    var cache = {}, idAllocator = 0;

    function SomeThing() {
        this.id = ++idAllocator; // The unique identifier, can be a string if desired
        cache[this.id] = {};
    }
    SomeThing.prototype.getPrivateVar = function() {
        var data = cache[this.id];
        return data && data.privateVar;
    };
    SomeThing.prototype.setPrivateVar = function(value) {
        cache[this.id].privateVar = value;
    };
    SomeThing.prototype.destroy = function() {
        delete cache[this.id];
    };

    return SomeThing;
})();

Here’s how that works: All of the functions are closures over the cache local variable in the outer scoping function. We index into that using the unique ID of the object, which gives us an object on which we put our private data members. When the code using the instance is done using it, that code must call destroy (which is a major downside to this pattern) so we remove the private data object from cache by deleting the property for our id.

Caveats and costs:

• You still have a public piece of data that is the key to your private data (id in the above)
• Users of the instances created by SomeThing must call destroy on those instances when they’re done with them. This is anathema to the way JavaScript’s garbage handling works, but it’s a requirement of the pattern above because otherwise you end up with cruft building up in the cache object.
• (I wouldn’t worry about this one) Eventually, if you’re using the automatic id values above, you’ll run out of them, if your app creates and destroys a lot of these instances. But JavaScript numbers go very high up indeed, and if that’s an issue just find a different way to allocate IDs rather than the simplistic always-increasing system above.

I haven’t had to use the pattern above in my work yet, but I expect there are use-cases for it involving thousands of SomeThing instances and thus the desire not to have per-instance functions.

---

Side note: In the above, I changed someThing to SomeThing. In JavaScript, the standard practice is for the names of normal functions to start with a lower-case letter, and for the names of constructor functions (ones you use with new) to start with a capital letter. Since SomeThing is meant to be used with new, I capped it. This is only convention, but it’s an overwhelmingly popular one and, of course, it’s used within the language definition itself (Date is a constructor, setHours is a function).