Initializing a global namespace object
in [JavaScript]
|
Prev: FYI: Creating circular references is a perfectly OK thing to do.
Next: Volunteers Requested for open source publishing project
From: Asen Bozhilov on 27 Jul 2010 10:51 Stanimir Stamenkov wrote: > So until we start making more sense of the code organization I want to > introduce a single object acting as global namespace for our own code. > And yes, the files are not loaded in random order but then different > sets of them is included in different documents, so I want more > foolproof fix for the initial namespace problem hence I need to set it > up independently in every file, but in non-destructive manner. I understand the problem, but I do not understand why do not create one file with name e.g. "core.js"? There will be the declaration/ initialization of `MYNS' and some utilities which can be used by other modules. By this approach in the future if you want to create utility which is shared between every module of application, you just should define as property of `MYNS' in "core.js". In the other hand in some module if I want to use something from "core.js" it is quite easy because I can't create this module without "core.js". > Yes, I'm native Bulgarian speaking. Good to know. On private messages we can talk on Bulgarian. Regards!
From: David Mark on 28 Jul 2010 14:42 On Jul 27, 7:43 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > David Mark wrote: > > On Jul 26, 9:32 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > >> The one practical advantage to [a single-line namespace declaration] > >> I know of is that it's much easier to introduce it in the sort of > >> environment the OP describes, when there is a team that needs to be > >> convinced that namespaces are not difficult. It's easy to point to > >> a one-liner to demonstrate how easy it is to start using namespaces. > > > If the team is having trouble wrapping their brains around global > > variable declarations (a la Jorge), then they've got bigger problems > > to sort out. > > Perhaps, but most teams do have their issues. I think that goes without saying. > If the issues can be > reduced by one using such a simple method, it certainly seems worth it > to me. No, teaching pattern memorization will not lead to greater understanding. > > > They should also understand that there is no such thing > > as a "namespace" in JS. It's a global variable referencing an > > object. Calling it something else implies that it is somehow > > different from all other native objects, which it is not. That's > > where the confusion starts. > > I'm not sure what "namespace" means to you that a global variable > referencing an object would not cover. My point had nothing to do with what the term "namespace" means to me. It's about the confusion it can cause for beginners. > I like Wikipedia's definition: Irrelevant.
From: Scott Sauyet on 28 Jul 2010 22:16 David Mark wrote: > On Jul 27, 7:43 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > >> David Mark wrote: >>> If the team is having trouble wrapping their brains around global >>> variable declarations (a la Jorge), then they've got bigger problems >>> to sort out. > >> Perhaps, but most teams do have their issues. > > I think that goes without saying. > >> If the issues can be >> reduced by one using such a simple method, it certainly seems worth it >> to me. > > No, teaching pattern memorization will not lead to greater > understanding. Have you always worked alone? Many of us have worked on teams that require some common standards of coding. I've tried to introduce standards on many different teams that used this sort of namespace as a means of avoiding global variables. In fact I usually try to go a little further and require that there are only a few properties of that namespace object, a few set by the server, and then some objects that hold functions relevant to some major part of the domain, each exposing only the minimal public interface required. Often one of those has a only a single public "init" method. This is certainly an architectural or design pattern, but is not so much rote memorization as one practical way to organize JS code. >>> They should also understand that there is no such thing >>> as a "namespace" in JS. It's a global variable referencing an >>> object. Calling it something else implies that it is somehow >>> different from all other native objects, which it is not. That's >>> where the confusion starts. >> I'm not sure what "namespace" means to you that a global variable >> referencing an object would not cover. > > My point had nothing to do with what the term "namespace" means to > me. It's about the confusion it can cause for beginners. If the definition of "namespace" as commonly understood covers exactly the sort of construct under question, then there is little room for confusion. Why do you think it could cause problems? If you didn't understand it, I am disagreeing entirely that there is no such thing as a namespace in JS; I believe the construct under question ("var MYNS = MYNS || {}") defines a namesapce. Who would this confuse, and why? -- Scott
From: David Mark on 28 Jul 2010 23:03 On Jul 28, 10:16 pm, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > David Mark wrote: > > On Jul 27, 7:43 am, Scott Sauyet <scott.sau...(a)gmail.com> wrote: > > >> David Mark wrote: > >>> If the team is having trouble wrapping their brains around global > >>> variable declarations (a la Jorge), then they've got bigger problems > >>> to sort out. > > >> Perhaps, but most teams do have their issues. > > > I think that goes without saying. > > >> If the issues can be > >> reduced by one using such a simple method, it certainly seems worth it > >> to me. > > > No, teaching pattern memorization will not lead to greater > > understanding. > > Have you always worked alone? Of course not. Try Googling or just visit my LinkedIn profile. Or are you just trying to be comical? > Many of us have worked on teams that > require some common standards of coding. Us? Well, count me in whatever group you are speaking for. :) > I've tried to introduce > standards on many different teams that used this sort of namespace as > a means of avoiding global variables. Standards for declaring global variables? You are welcome to either of the two examples I posted. Can't go wrong. :) > > In fact I usually try to go a little further and require that there > are only a few properties of that namespace object, a few set by the > server, and then some objects that hold functions relevant to some > major part of the domain, each exposing only the minimal public > interface required. I think we are drifting here. > Often one of those has a only a single public > "init" method. This is certainly an architectural or design pattern, > but is not so much rote memorization as one practical way to organize > JS code. Now I'm sure of it. I'm finished with this discussion. In short, so- called "namespace objects" are virtually always self-imposed performance penalties. At most you need one to keep the global scope clean and often you don't even need that. And as they are no different from any other object in JS, there's no need to give them special names.
From: Karl Tikjøb Krukow on 29 Jul 2010 01:45
On 26/07/10 14.26, Stanimir Stamenkov wrote: > As the number of utility functions I write increases I've started to > use a global variable acting as namespace for my functions. Given my > functions are spread in couple of .js files and the order of loading > is not significant (documents may include random combination of the > files) I've wondered how it is best to initialize the namespace > object. I've a general function, similar to the following in the past var namespace = (function() { var globalObject = this; function namespace(/*String*/ spec) { var i, part, context = globalObject; while (true) { i = spec.indexOf("."); if (i < 0) { part = spec; } else { part = spec.substring(0, i); spec = spec.substring(i + 1); } context[part] = context[part] || {}; context = context[part]; if (i < 0) { break; } } return context; } })(); //usage namespace("App.Module").init = function(){ var A = App, M = A.Module;//short names, fast lookup //... }; If wanted, we can define a "using" function namespace("App.Module"); using(App.Module).run(function(m) { //m refers to App.Module }); Karl. |