Initializing a global namespace object

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

 

[Scott Sauyet]

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_(computer_science)>

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

 

[Asen Bozhilov]

Asen Bozhilov wrote:

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]

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]

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.

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]

I think that goes without saying.


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.

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?

 

[David Mark]

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]

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]

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) {

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.

 

[Richard Cornford]

On Jul 29, 3:16 am, Scott Sauyet wrote:

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]

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.

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!

 

[David Mark]

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.

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]

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.

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]

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

 

[David Mark]

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?  

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.



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]

  <snip>

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

Correct on all counts.

 

[Scott Sauyet]

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.

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?

 

[David Mark]

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.

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]

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*

 

[David Mark]

*PLONK*

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.