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.
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.
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,
...
}
})();
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With