views:

82

answers:

3

In a project I am working on I am structuring my code as follows

MyLib = {
    AField:0,

    ASubNamespace:{
        AnotherField:"value",

        AClass:function(param) {
            this.classField = param;

            this.classFunction = function(){
                // stuff
            }
        }
    },

    AnotherClass:function(param) {
        this.classField = param;

        this.classFunction = function(){
            // stuff
        }
    }
}

and so on like that to do stuff like:

var anInstance = new MyLib.ASubNamespace.AClass("A parameter.");

Is this the right way to go about achieving namespacing? Are there performance hits, and if so, how drastic? Do performance degradations stack as I nest deeper? Are there any other issues I should be aware of when using this structure?

I care about every little bit of performance because it's a library for realtime graphics, so I'm taking any overhead very seriously.

+3  A: 

I suggest namespacing is a critical part of writing maintainable JavaScript - especially if you work with a team of developers.

Performance issues related to namespacing should be minimal if you compress/minimize your code on the way to production.

Here is an SO discussion of alternative ways to use namespaces.

Upper Stage
+2  A: 

Namespacing your JavaScript is critical to avoid potential conflicts and overwrites. This is specially true when your JS will land up in foreign environments where external JS can also reside.

With that said, there is a performance hit because of namespacing, simply because the interpreter now has to follow a longer chain to access the required function/property.

For example, something like

  var myProperty;

is accessed a little faster as compared to :

 myNameSpace.module1.myProperty;

I think the difference in speed is not much unless you namespace extremely deeply and the advantage of avoiding potential conflicts is a big plus of namespacing.

But still, it is always good to keep this issue in mind.

Rajat
+2  A: 

When you structure your code as a big giant object-property hierarchy, you sometimes have issues where MyNamespaceObj.prop1 isn't available to MyNamespaceObj.prop2 yet. And then there's the fact that you often end up typing fully qualified names a lot throughout the code.

I'm starting to find I prefer doing something like this:

MyNamespaceObj = (function () {

    // lots of code/definitions that have local scope
    var internallyDefinedItem1 = function (n) { /* ... */ }
    var internallyDefinedItem2 = {
        foo: internallyDefinedItem1(532),
        bar: totallyPrivateNeverExportedFunction(17)
    }
    var totallyPrivateNeverExportedVar = 'blahblahblah';
    function totallyPrivateNeverExportedFunction (x) {
       /* ... */
    }

    return {
        exportedItem1: internallyDefinedItem1,
        exportedItem2: internallyDefinedItem2,
        ...
    }
})();
Weston C
I've found while working on the project that necessitated this question originally that having anything be entirely private can be rather detrimental to debugging as it's a pain to get at those values at runtime.
Bjartr
That's true enough. I've mostly gotten around it by writing functions that log values to a console at runtime while debugging (and having them striped out), but it's definitely annoying that it's difficult in some of the debuggers out there to set a watch on an expression with limited local scope. I think that's mostly a tool weakness rather than a technique weakness, though. Hopefully one that gets resolved over time.
Weston C