Initializing a global namespace object

[Stanimir Stamenkov]

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 generally use the following construct in my .js files:

(function () {
if (typeof MYNS === "undefined") {
MYNS = { };
}
// Add stuff to MYNS...
}());

But then running this through JSLint tells me: "'MYNS' is not
defined". Changing the code to:

(function () {
if (typeof this.MYNS === "undefined") {
this.MYNS = { };
}
// Add stuff to MYNS...
}());

results in no JSLint errors but then it lists 'MYNS' as member and
not a global variable, if it matters at all. Which of the both
forms is recommended? Should I just tell JSLint 'MYNS' is a
predefined global?

--
Stanimir

[Asen Bozhilov]

Stanimir Stamenkov wrote:

> results in no JSLint errors but then it lists 'MYNS' as member and
> not a global variable, if it matters at all.  Which of the both
> forms is recommended?  Should I just tell JSLint 'MYNS' is a
> predefined global?

Both are not good. First, because use undeclared assignment. In the
second approach the problem is in ES5 environment. The `this'
associated with that execution context in strict mode must be
`undefined'. So you will get TypeError.

I don't see any benefits by your code. The order of loading is always
mandatory and the users of your code must be know that. I have never
liked such a definition of a namespace. If I want namespace I do:

var MYNS = {};

It's enough. Should I care about third party conflicts? I don't think
so. If there are third party conflicts this means wrong usage of my
code and my recommendations. And for environment which I suggest to be
used this code I am sure that `MYNS' does not refer both host or built-
in object.

What is your native language? Is it Bulgarian?

[Ry Nohryb]

Use window.MYNS instead of this.MYNS, and, in order to avoid
overwriting/destroying a possibly pre-existing/previously-defined
MYNS :

window.MYNS= window.MYNS || {};

JSLint then won't complain because global vars are properties of the
global object, and the 'window' and 'self' globals are references to
the Global Object itself:

GlobalObject.window === GlobalObject.self === GlobalObject ===
(function(){return this})()

and thus window.someGlobalVarName is only an explicit way of saying
"hey, this is a global var !".
--
Jorge.

[Stanimir Stamenkov]

Mon, 26 Jul 2010 20:18:00 +0000 (UTC), /Ry Nohryb/:

> Use window.MYNS instead of this.MYNS, and, in order to avoid
> overwriting/destroying a possibly pre-existing/previously-defined MYNS :
>
> window.MYNS= window.MYNS || {};

I decided to use this.MYNS instead of window.MYNS as in the given case,
and as far as my knowledge goes, 'this' should refer to the global
object and I don't really care (or want to depend) it happens to be the
'window' one having a self references as 'window' and 'self'
properties. But as Asen Bozhilov pointed in another reply, I now see
'this' is no safer to use. I currently have no knowledge of ES5 and how
browsers scripts should operate in that environment, but I'll probably
stick with your suggestion until I get to understand more. :-)

> JSLint then won't complain because global vars are properties of the
> global object, and the 'window' and 'self' globals are references to
> the Global Object itself:
>
> GlobalObject.window === GlobalObject.self === GlobalObject ===
> (function(){return this})()
>
> and thus window.someGlobalVarName is only an explicit way of saying
> "hey, this is a global var !".

JSLint also complained about 'window' not defined until I tell it
'window' is a predefined symbol explicitly, although I had checked the
"Assume a browser" option, also. Is it o.k. if I do:

(function () {
var MYNS = window.MYNS = window.MYNS || { };
MYNS.fooBar = function () {
// ...
};
}());

so I don't have to qualify every MYNS reference in the closure, next?

--
Stanimir

[Stanimir Stamenkov]

Mon, 26 Jul 2010 12:47:48 -0700 (PDT), /Asen Bozhilov/:

> Both are not good. First, because use undeclared assignment. In the
> second approach the problem is in ES5 environment. The `this'
> associated with that execution context in strict mode must be
> `undefined'. So you will get TypeError.

O.k. I understand. I generally don't have such advanced knowledge of
JavaScript. Do you know which browsers currently implement the ES5
specification and support strict mode?

> I don't see any benefits by your code. The order of loading is always
> mandatory and the users of your code must be know that. I have never
> liked such a definition of a namespace. If I want namespace I do:
>
> var MYNS = {};

> (...)

The problem is I have a bunch of .js files which happen to be written by
multiple people and contain just "flying" global functions, and I want
to convince all the guys writing them we should at least start using a
separate space than the global object. Then we could also start
thinking of giving the code finer modularization.

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.

> What is your native language? Is it Bulgarian?

Yes, I'm native Bulgarian speaking.

--
Stanimir

[Ry Nohryb]

If this code runs at the top level (if it's not wrapped in an eval()
nor inside any other function), I'd write it so:

var MYNS= window.MYNS || { };
(function () {

//Use MYNS here freely, it's already a global.

})();

The window.MYNS in the var MYNS declaration is there just to make
JSLint happy. If JSLint doesn't "hurt your feelings", you can write it
without the window. :

var MYNS= MYNS || { };

But it (JSLint) will probably complain about the use of an undeclared
MYNS because it's being used prior to its declaration.
--
Jorge.

[Ry Nohryb]

On Jul 27, 1:49 am, Ry Nohryb <jo...@jorgechamorro.com> wrote:
>
> But it (JSLint) will probably complain about the use of an undeclared
> MYNS because it's being used prior to its declaration.

Well, I mean, at that point it's -probably- undefined, but not
undeclared.
--
Jorge.

[JR]

Hi,
I think of (function () {})() as a means of avoiding global variables.
But if you want / need a global variable then you should follow
Jorge's advice or do that:

(function() {
var global = this;
global.MYNS = { };
// to be continued.
})();

But it seems easier to write only var MYNS = { } than the module
pattern (function() {})()

--
JR

[RobG]

On Jul 26, 10:26 pm, Stanimir Stamenkov <s7a...@netscape.net> 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 generally use the following construct in my .js files:
>
> (function () {
>      if (typeof MYNS === "undefined") {
>          MYNS = { };

Don't be coy about creating global variables. If you want to create
one, declare it right up front. Just before the anonymous function,
use:

var MYNS;

Note that if MYNS already exists, the extra variable declaration has
no impact, so it is absolutely safe. Anyone reading your code will see
it right at the top and know it's yours.

>      }
>      // Add stuff to MYNS...
>
> }());
>
> But then running this through JSLint tells me: "'MYNS' is not
> defined".  Changing the code to:
>
> (function () {
>      if (typeof this.MYNS === "undefined") {
>          this.MYNS = { };
>      }
>      // Add stuff to MYNS...

Just declare it before the function.

> }());
>
> results in no JSLint errors but then it lists 'MYNS' as member and
> not a global variable, if it matters at all.  Which of the both
> forms is recommended?  Should I just tell JSLint 'MYNS' is a
> predefined global?

If you want MYNS to be a native Object object, then you should test
explicitly for that. If you want to be strict, then the following
should run as global code:

var MYNS;
if (typeof MYNS != 'object') {
MYNS = {};
}

Now you know excatly what MYNS is (and may have stomped on someone
else's MYNS, but that's for the user of your code to fix).

Don't fall for junk like the following (which is in a commercial
product in wide use where I work):

if (dwr == null) var dwr = {};

Which infers that variables can be conditionally decalred (they can't)
and depends on the truthiness of undefined == null. The author
probably should have written:

var dwr;
if (typeof dwr == 'undefined') {
dwr = {};
}

Anyhow, it is probably sufficient to use the following as global code:

var MYNS = MYNS || {};

--
Rob

[Scott Sauyet]

On Jul 26, 8:26 am, Stanimir Stamenkov <s7a...@netscape.net> 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 had to do this a number of times recently, and this has served my
purposes well:

var MYNS = MYNS || {};

at the top of each JS file that uses the namespace. And I simply tell
JSLint that this is a global variable.

When I can't put the global namespace in a JSLint configuration file,
I often format it as

/* global MYNS */ var MYNS = MYNS || {};

to keep it to a single line.

That seems fairly simple, and I don't know if there are any underlying
issues that I haven't considered, but it works well for me.

--
Scott

[David Mark]

You've finally lost it, haven't you Jorge?

var MYNS;

if (!MYNS) {
MYNS = {};
}

Or:-

var MYNS;

MYNS = MYNS || {};

>
> JSLint then won't complain because global vars are properties of the
> global object, and the 'window' and 'self' globals are references to
> the Global Object itself:

Not that it matters a whit, but last I checked, JSLint decried the use
of - window - as an "implied global". (!)

>
> GlobalObject.window === GlobalObject.self === GlobalObject ===
> (function(){return this})()

As you've been told a thousand times, that proves nothing.

>
> and thus window.someGlobalVarName is only an explicit way of saying
> "hey, this is a global var !".

Get better Jorge!

[David Mark]

On Jul 26, 3:47 pm, Asen Bozhilov <asen.bozhi...@gmail.com> wrote:
> Stanimir Stamenkov wrote:
> > results in no JSLint errors but then it lists 'MYNS' as member and
> > not a global variable, if it matters at all.  Which of the both
> > forms is recommended?  Should I just tell JSLint 'MYNS' is a
> > predefined global?
>
> Both are not good. First, because use undeclared assignment. In the
> second approach the problem is in ES5 environment. The `this'
> associated with that execution context in strict mode must be
> `undefined'. So you will get TypeError.

I don't see the strict mode problem to be an issue as you would have
to explicitly require strict mode in the code.

[David Mark]

And JFTR, there is no reason at all that such code should be inside of
an anonymous one-off function.

>
> var MYNS= window.MYNS || { };

Really?! That's not progress, Jorge.

> (function () {
>
>   //Use MYNS here freely, it's already a global.
>
> })();
>
> The window.MYNS in the var MYNS declaration is there just to make
> JSLint happy.

For one, making JSLint "happy" is not a prerequisite. You can't take
arbitrary orders from a script, you need to think about what you are
doing. Granted, *most* of JSLint's missives are useful.

> If JSLint doesn't "hurt your feelings", you can write it
> without the window. :
>
> var MYNS= MYNS || { };

As mentioned, the competent version is:-

var MYNS;

if (!MYNS) {
MYNS = {};
}

...or:-

var MYNS;

MYNS = MYNS || {};

You seem to be fouling this up in some sort of ill-advised quest to
cram the whole thing on to one line. Leave that to the minifier. ;)

>
> But it (JSLint) will probably complain about the use of an undeclared
> MYNS because it's being used prior to its declaration.

I guarantee to you JSLint won't say a peep about either of the
versions I posted. In your mind, wouldn't that make them correct? :)

[David Mark]

You know, for somebody who decries the "decline" of this newsgroup,
you should know that waffling over such a simple question/answer is
not helping matters at all. ;)

[David Mark]

Forgot the check for null:-

var MYNS;
if (!MYNS || typeof MYNS != 'object') {
  MYNS = {};
}

>
> Now you know excatly what MYNS is (and may have stomped on someone
> else's MYNS, but that's for the user of your code to fix).
>
> Don't fall for junk like the following (which is in a commercial
> product in wide use where I work):
>
>   if (dwr == null) var dwr = {};

Dojo-esque. :( You know they un-declared all of their globals about
a year ago because somebody suggested it would be "faster". :)

>
> Which infers that variables can be conditionally decalred (they can't)
> and depends on the truthiness of undefined == null. The author
> probably should have written:
>
>   var dwr;
>   if (typeof dwr == 'undefined') {
>     dwr = {};
>   }

Or just used boolean type conversion as any "falsey" value is going to
be undesirable.

var dwr;

if (!dwr) {
dwr = {};
}

>
> Anyhow, it is probably sufficient to use the following as global code:
>
>   var MYNS = MYNS || {};
>

That will work as well. I don't particularly care for it, but that's
a matter of personal taste.

[Scott Sauyet]

The one practical advantage to it 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.

--
Scott

[David Mark]

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. 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.

[Stanimir Stamenkov]

Tue, 27 Jul 2010 00:57:31 +0000 (UTC), /RobG/:

> Don't be coy about creating global variables. If you want to create
> one, declare it right up front. Just before the anonymous function, use:
>
> var MYNS;
>
> Note that if MYNS already exists, the extra variable declaration has
> no impact, so it is absolutely safe. Anyone reading your code will see
> it right at the top and know it's yours.

Ah, thanks. I was not sure whether the duplicate declaration in
different files would be permissible, i.e. it wouldn't destroy the value
of previously declared and initialized variable. I should have just
tried it, but it is good to know it is all right in theory, too.

> Anyhow, it is probably sufficient to use the following as global code:
>
> var MYNS = MYNS || {};

So I'll stick with this at the beginning of the file.

--
Stanimir

[RobG]

On Jul 27, 4:08 pm, Stanimir Stamenkov <s7a...@netscape.net> wrote:
> Tue, 27 Jul 2010 00:57:31 +0000 (UTC), /RobG/:
>
> > Don't be coy about creating global variables. If you want to create
> > one, declare it right up front. Just before the anonymous function, use:
>
> > var MYNS;
>
> > Note that if MYNS already exists, the extra variable declaration has
> > no impact, so it is absolutely safe. Anyone reading your code will see
> > it right at the top and know it's yours.
>
> Ah, thanks.  I was not sure whether the duplicate declaration in
> different files would be permissible, i.e. it wouldn't destroy the value
> of previously declared and initialized variable.  I should have just
> tried it, but it is good to know it is all right in theory, too.

You could always read the specification[1]: ECMA-262 ed 3, §10.1.3
Variable Instantiation, the last part of which says:

"If there is already a property of the variable object with
the name of a declared variable, the value of the property
and its attributes are not changed. ... In particular, if a
declared variable has the same name as a declared function
or formal parameter, the variable declaration does not
disturb the existing property"

> > Anyhow, it is probably sufficient to use the following as global code:
>
> > var MYNS = MYNS || {};
>
> So I'll stick with this at the beginning of the file.

Of *each* file. ;-)

1. It's always good to find the relevant part of the spec to confirm
things. It's not an easy document to read and comprehend (I find it
quite difficult). If you keep using it as a reference, and search or
ask here if there are things you can't find or figure out, then bit by
bit it starts to make sense (mostly).

--
Rob

[Stanimir Stamenkov]

Tue, 27 Jul 2010 07:09:41 +0000 (UTC), /RobG/:

> On Jul 27, 4:08 pm, Stanimir Stamenkov <s7a...@netscape.net> wrote:
>> Tue, 27 Jul 2010 00:57:31 +0000 (UTC), /RobG/:
>>

>>> Anyhow, it is probably sufficient to use the following as global code:
>>>
>>> var MYNS = MYNS || {};
>>
>> So I'll stick with this at the beginning of the file.
>
> Of *each* file. ;-)

Yes, my mistake. I've really meant "at beginning of each file". :-)

> 1. It's always good to find the relevant part of the spec to confirm
> things. It's not an easy document to read and comprehend (I find it
> quite difficult). If you keep using it as a reference, and search or
> ask here if there are things you can't find or figure out, then bit by
> bit it starts to make sense (mostly).

Seems the best way to go. Thank you and the rest who provided
valuable guidance.

--
Stanimir

[Stefan Weiss]

On 27/07/10 03:06, David Mark wrote:
> var MYNS;
>
> if (!MYNS) {
> MYNS = {};
> }
>
> Or:-
>
> var MYNS;
>
> MYNS = MYNS || {};

What's wrong with

var MYNS = MYNS || {};

?

--
stefan

[Stefan Weiss]

On 27/07/10 10:51, Stefan Weiss wrote:
> What's wrong with
>
> var MYNS = MYNS || {};
>
> ?

I should have read the entire thread before replying... sorry.

--
stefan

[Ry Nohryb]

On Jul 27, 4:36 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> If the team is having trouble wrapping their brains around global
> variable declarations (a la Jorge)

LOL.
--
Jorge.

[Stanimir Stamenkov]

Mon, 26 Jul 2010 15:26:53 +0300, /David Mark/:

> ... 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.

In my initial post I've written: "use a global variable acting as
namespace". Do you think the given wording is confusing?

In C++ and Java classes act as namespaces for their static members,
for example, but classes are not namespaces. Java also doesn't have
namespaces but packages. I think most people are aware, number of
concepts are established differently in different programming
environments.

--
Stanimir

[Scott Sauyet]

David Mark wrote:
> On Jul 26, 9:32 pm, Scott Sauyet <scott.sau...@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. If the issues can be
reduced by one using such a simple method, it certainly seems worth it
to me.

> 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. I like Wikipedia's definition:

| A namespace is an abstract container or environment created
| to hold a logical grouping of unique identifiers or symbols
| (i.e., names).

-- <http://en.wikipedia.org/wiki/Namespace_%28computer_science%29>

That's certainly how I use such constructs in Javascript.

--
Scott

[Asen Bozhilov]

David Mark wrote:
> Asen Bozhilov wrote:

> > Both are not good. First, because use undeclared assignment. In the
> > second approach the problem is in ES5 environment. The `this'
> > associated with that execution context in strict mode must be
> > `undefined'. So you will get TypeError.
>
> I don't see the strict mode problem to be an issue as you would have
> to explicitly require strict mode in the code.

Definitely, but I would prefer to use а code which I can easy migrate
in ES5 environment with strict-mode. Although I do not like some
things from ES5 during development process I would prefer to use
strict variant of the language.

[Asen Bozhilov]

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!

[David Mark]

On Jul 27, 7:43 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 26, 9:32 pm, Scott Sauyet <scott.sau...@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.

[Scott Sauyet]

David Mark wrote:
> On Jul 27, 7:43 am, Scott Sauyet <scott.sau...@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

[David Mark]

On Jul 28, 10:16 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 27, 7:43 am, Scott Sauyet <scott.sau...@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.

[Karl Tikjøb Krukow]

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.

[Karl Tikjøb Krukow]

On 29/07/10 07.45, Karl Tikjøb Krukow wrote:
> 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

I've *used* a ...

>
> var namespace = (function() {
> var globalObject = this;

return function (/*String*/ spec) {

[Richard Cornford]

On Jul 29, 3:16 am, Scott Sauyet wrote:
<snip>

> If the definition of "namespace" as commonly understood covers
> exactly the sort of construct under question, then there is
> little room for confusion.

Unfortunately javascript tends to suffer from things that are commonly
misunderstood. How many ES3 "bind" functions have you seen associating
the word 'scope' with what will be the - this - value? That (or the
underlying misconception(s)) hasn't helped people understand
javascript's lexical scope or its runtime determined handling of -
this - values. Indeed that particular misuse of terminology has
occasionally gone as far as preventing people from actually asking the
question that they wanted an answer to.

> 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?

You would end up with people talking about 'javascript namespaces';
things that don't actually exist (at least in ES3, introducing the
possibility that they are talking about JScript.net or something),
when they wanted to be talking about 'namespaces' implemented with (or
in) javascript (which certainly can exist). The distinction may seem
pedantic but when the use of a few extra words can eliminate ambiguity
then that justifies using those words.

Richard.

[Scott Sauyet]

I wasn't arguing for the phrase "javascript namespaces", only for
"namespaces" and since I never try to introduce a "namespace" function
or treat "namespace" as a keyword, I don't see the potential for
confusion. Perhaps that's just me being naive.

My only recent point in this thread was to counter David Mark's
assertion that:

| They should also understand that there is no such thing as a

| "namespace" in JS. It's a global variable referencing an object.

With the way discussions often proceed around here, I'd be crazy to
complain about a single instance of pedantry! :-)

--
Scott

[David Mark]

And as has been explained to you, you have no counter to that. JS
(referring to ES3 of course) has no concept of namespaces. You may
implement whatever you want in JS and call it whatever you want, but
that doesn't make it part of JS.

>
> With the way discussions often proceed around here, I'd be crazy to
> complain about a single instance of pedantry!  :-)
>

So you were being pedantic and you'd be crazy to complain about it? I
don't follow.

[Scott Sauyet]

David Mark wrote:
> On Jul 29, 8:21 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>> Richard Cornford wrote:
>>> On Jul 29, 3:16 am, Scott Sauyet wrote:
>>>> 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?
>
>>> You would end up with people talking about 'javascript namespaces';

>>> things that don't actually exist [ ... ].

>
>> I wasn't arguing for the phrase "javascript namespaces", only for
>> "namespaces" and since I never try to introduce a "namespace" function
>> or treat "namespace" as a keyword, I don't see the potential for
>> confusion.  Perhaps that's just me being naive.
>
>> My only recent point in this thread was to counter David Mark's
>> assertion that:
>
>> | They should also understand that there is no such thing as a
>> | "namespace" in JS.  It's a global variable referencing an object.
>
> And as has been explained to you, you have no counter to that.  JS
> (referring to ES3 of course) has no concept of namespaces.  You may
> implement whatever you want in JS and call it whatever you want, but
> that doesn't make it part of JS.

Well. so much for your being done with this discussion, huh? :-)

As already made abundantly clear to anyone who cares, the constructs
under question are namespaces in JS under any reasonable definition of
"namespace". No one ever suggested that there was some native
language support for namespaces.

>> With the way discussions often proceed around here, I'd be crazy to
>> complain about a single instance of pedantry!  :-)
>
> So you were being pedantic and you'd be crazy to complain about it?  I
> don't follow.

You really need to learn to read before you respond.

-- Scott

[John G Harris]

On Thu, 29 Jul 2010 at 06:02:44, in comp.lang.javascript, David Mark
wrote:

<snip>

>And as has been explained to you, you have no counter to that. JS
>(referring to ES3 of course) has no concept of namespaces. You may
>implement whatever you want in JS and call it whatever you want, but
>that doesn't make it part of JS.

<snip>

Equally, lists are not part of JS.
Nor are stacks.
Nor are trees.
Nor are user interfaces.

John
--
John Harris

[David Mark]

Ah, the indefatigable match announcer.

>
> As already made abundantly clear to anyone who cares, the constructs
> under question are namespaces in JS under any reasonable definition of
> "namespace".  No one ever suggested that there was some native
> language support for namespaces.
>
> >> With the way discussions often proceed around here, I'd be crazy to
> >> complain about a single instance of pedantry!  :-)
>
> > So you were being pedantic and you'd be crazy to complain about it?  I
> > don't follow.
>
> You really need to learn to read before you respond.

No, you need to learn to write more clearly. That last paragraph made
no sense at all in context.

[David Mark]

Correct on all counts.

[Scott Sauyet]

David Mark wrote:
> On Jul 29, 10:00 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> > David Mark wrote:
>> Well. so much for your being done with this discussion, huh?  :-)
>
> Ah, the indefatigable match announcer.

No, I just like to point out inconsistencies and other intellectual
dishonesties. You just happen to be a particularly easy source of
both.

>>>> With the way discussions often proceed around here, I'd be crazy to
>>>> complain about a single instance of pedantry!  :-)
>
>>> So you were being pedantic and you'd be crazy to complain about it?  I
>>> don't follow.
>
>> You really need to learn to read before you respond.
>
> No, you need to learn to write more clearly.  That last paragraph made
> no sense at all in context.

Perhaps you don't know what "context" means. Did you actually read my
response to Richard Cornford, and his post I responded to, or did you
zero in on a few choice keywords? For the record, the post I
responded to included the following, which I quoted immediately above
the section of my post we're discussing:

| You would end up with people talking about 'javascript namespaces';

| things that don't actually exist (at least in ES3, introducing the
| possibility that they are talking about JScript.net or something),
| when they wanted to be talking about 'namespaces' implemented with
(or
| in) javascript (which certainly can exist). The distinction may seem
| pedantic but when the use of a few extra words can eliminate
ambiguity
| then that justifies using those words.

You've said before that English is your native language; you do
recognize the connection between the words "pedantic" and "pedantry",
right?

--
Scott

[David Mark]

On Jul 30, 7:42 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> David Mark wrote:
> > On Jul 29, 10:00 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
> > > David Mark wrote:
> >> Well. so much for your being done with this discussion, huh?  :-)
>
> > Ah, the indefatigable match announcer.
>
> No, I just like to point out inconsistencies and other intellectual
> dishonesties.

An irritating pundit, basically. And the use of the term
"intellectual dishonesties" in this context (or in Usenet in general)
is beyond laughable. Do you read your stuff before you post? Try it
in front of a mirror. ;)

> You just happen to be a particularly easy source of
> both.

No, I've been consistent to a fault here for years. You are simple a
very green participant with wide eyes and a big mouth.

>
> >>>> With the way discussions often proceed around here, I'd be crazy to
> >>>> complain about a single instance of pedantry!  :-)
>
> >>> So you were being pedantic and you'd be crazy to complain about it?  I
> >>> don't follow.
>
> >> You really need to learn to read before you respond.
>
> > No, you need to learn to write more clearly.  That last paragraph made
> > no sense at all in context.
>
> Perhaps you don't know what "context" means.

Then again, perhaps I do.

> Did you actually read my
> response to Richard Cornford, and his post I responded to, or did you
> zero in on a few choice keywords?

The former of course.

> For the record, the post I
> responded to included the following, which I quoted immediately above
> the section of my post we're discussing:

For the record? Here we go again with "then I said this, then he said
that, then I said this". Was the basic discussion really that hard to
follow?

>
> | You would end up with people talking about 'javascript namespaces';
> | things that don't actually exist (at least in ES3, introducing the
> | possibility that they are talking about JScript.net or something),
> | when they wanted to be talking about 'namespaces' implemented with
> (or
> | in) javascript (which certainly can exist). The distinction may seem
> | pedantic but when the use of a few extra words can eliminate
> ambiguity
> | then that justifies using those words.
>
> You've said before that English is your native language;

That should go without saying.

> you do
> recognize the connection between the words "pedantic" and "pedantry",
> right?
>

Seeing as I used the word "pedantic" to describe your ridiculous,
seemingly unending quest to prove an irrelevant point in a discussion
that has long reached its logical conclusion, what do you think?

Again, your tacked-on "oh, I was really right after all" response
about "pedantry" made no sense in context. Re-read what I said (and
what I responded to) and please don't feel the need to copy and paste
it. The posts don't go away, so there's no need for instant
replays. ;)

[Scott Sauyet]

David Mark wrote:
> On Jul 30, 7:42 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>
>> David Mark wrote:
>>> On Jul 29, 10:00 am, Scott Sauyet <scott.sau...@gmail.com> wrote:
>>> > David Mark wrote:
>>>> Well. so much for your being done with this discussion, huh?  :-)
>
>>> Ah, the indefatigable match announcer.
>
>> No, I just like to point out inconsistencies and other intellectual
>> dishonesties.
>
> An irritating pundit, basically.  And the use of the term
> "intellectual dishonesties" in this context (or in Usenet in general)
> is beyond laughable.  Do you read your stuff before you post?  Try it
> in front of a mirror.  ;)

*PLONK*

--
Scott

[David Mark]

That's the best news I've heard all day. It's not like you respond
often, but it's virtually always irritating and pointless.