Javascript Module Pattern Memory Footprint and Performance

Question

I am using the Javascript Module Pattern to try and implement C# enumeration-like functionality. I have two ways that I am currently thinking about implementing this functionality but I do not understand all the benefits or advantages of one way versus the other.

Here is implementation 1:

var MyApp = (function (app) {

    // Private Variable
    var enums = {
        ActionStatus: {
            New: 1,
            Open: 2,
            Closed: 3
        }
    };

    // Public Method
    app.getEnum = function (path) {
        var value = enums;            
        var properties = path.split('.');
        for (var i = 0, len = properties.length; i < len; ++i) {
            value = value[properties[i]];
        }
        return value;
    };

    return app;

})(MyApp || {});

// Example usage
var status = MyApp.getEnum("ActionStatus.Open");

And now implementation 2:

var MyApp = (function (app) {

    // Public Property
    app.Enums = {
        ActionStatus: {
            New: 1,
            Open: 2,
            Closed: 3
        }
    };

    return app;

})(MyApp || {});

// Example usage
var status = MyApp.Enums.ActionStatus.Open;

The main difference is in using a "private" variable vs a "public" property to store the enums. I would think implementation 1 is a little slower but I was not sure if keeping the enums as "private" reduced the memory usage. Can anyone explain the difference in memory footprint and performance for the two (if any)? Any other suggestions/advice are appreciated.

Answer 1

...but I was not sure if keeping the enums as "private" reduced the memory usage

The opposite, if anything: You still have to have the enums object, and you have to have a function to access it.

In terms of speed, I wouldn't worry about it. The added function call won't make any real difference (I looked into it when worried about using the new forEach and such, and even on IE6 with its massively slow JS engine, it just doesn't matter).

In a couple of years, you'll probably be able to have the best of both worlds: Enums that are read-only, thanks to ECMAScript5's Object.defineProperties feature:

var Enums = Object.defineProperties({}, {
    ActionStatus: {
        value: Object.defineProperties({}, {
            New:    {value: 1},
            Open:   {value: 2},
            Closed: {value: 3}
        })
    }
});

// Usage
var n = Enums.ActionStatus.New; // 1

By default, properties created with defineProperties are read-only.

In fact, you can basically have that now if you add an ES5 "shim" to create Object.defineProperties on browsers that don't yet have it natively. The "shimmed" version would create read-write properties, since only the natively-supported version can really create read-only properties, but you can write the code now and know that it will work as you like on modern browsers (about half of all web surfers currently have them) while still working, just with less robustness, on less-modern ones.

And of course, EMCAScript6 may take things further, but that's still a future thing.