0
\$\begingroup\$

I have come up with an idea for adding privacy support in JavaScript. I haven't found something similar in the net, so I'm thinking it's probably because the idea is bad, but yet, I want to see some response, just to be sure.

var util = {
    s4: function() {
        return Math.floor((1 + Math.random()) * 0x10000)
                    .toString(16)
                    .substring(1);
    },

    guid: function() {
        return util.s4() + util.s4() + '-' + util.s4() + '-' + util.s4() + '-' +
                util.s4() + '-' + util.s4() + util.s4() + util.s4();
    }
};

// template
var Class = (function() {
    var privates = {};
    var getPrivates = function(obj) {
        return privates[ obj.getGUID() ];
    };

    function Class() {
        var guid = util.guid();
        privates[guid] = {};
        this.getGUID = function() {
            return guid;
        };
    };

    return Class;
})();

var MyClass = (function() {
    var privates = {};
    var getPrivates = function(obj) {
        return privates[ obj.getGUID() ];
    };

    function MyClass(a, b) {
        var guid = util.guid();
        privates[guid] = {};
        this.getGUID = function() {
            return guid;
        };

        var private = getPrivates(this);
        private.a = a;
        this.b = b;
    };

    return MyClass;
})();

var obj = new MyClass("private", "public");
console.log(obj.a, obj.b);
\$\endgroup\$
7
  • \$\begingroup\$ It's a silly example. A class with 2 construct parameters - a and b. a is private, b is public. The last line console.log(obj.a, obj.b); outputs "undefined", "public" \$\endgroup\$ Commented Jul 29, 2013 at 18:16
  • 4
    \$\begingroup\$ Interesting idea, but public / private support is generally solved using the module pattern. Does your approach offer a significant benefit to that? \$\endgroup\$ Commented Jul 29, 2013 at 18:17
  • \$\begingroup\$ This has been done and redone many times, see blog.niftysnippets.org/2013/05/… \$\endgroup\$ Commented Jul 29, 2013 at 18:20
  • \$\begingroup\$ Chris, maybe I'm wrong, but the module pattern doesn't return a constructor, but an object literal? \$\endgroup\$ Commented Jul 29, 2013 at 18:21
  • 1
    \$\begingroup\$ The module pattern is the practice of returning functions (generally members of something, the titular "module") that have scope-access to some variables that are inaccessible to the rest of the code. \$\endgroup\$ Commented Jul 29, 2013 at 18:26

1 Answer 1

2
\$\begingroup\$

Interesting question,

as mentioned in the comments, privacy support can be (better) achieved with modules, or with IFFE's.

On the whole your design is not sound, your GUID creation code is so weak in generating unique id's that you will have overlapping GUID's and (hard to reproduce) bugs.

Furthermore, the variables are not exactly private if you can iterate over privates and see all the values stored in there..

Finally, I think you might have a pretty good case for a double assignment here, this

var MyClass = (function() {
    var privates = {};
    var getPrivates = function(obj) {
        return privates[ obj.getGUID() ];
    };

    function MyClass(a, b) {
        var guid = util.guid();
        privates[guid] = {};
        this.getGUID = function() {
            return guid;
        };

        var private = getPrivates(this);
        private.a = a;
        this.b = b;
    };

    return MyClass;
})();

could be

var MyClass = (function() {
    var privates = {};

    function MyClass(a, b) {
        var private = privates[util.guid()] = {};
        private.a = a;
        this.b = b;
    };

    return MyClass;
})();

From a lint/hint perspective you have some semicolon trouble, but nothing too bad.

\$\endgroup\$

You must log in to answer this question.