By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,474 Members | 1,267 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,474 IT Pros & Developers. It's quick & easy.

Dealing with possible namespace clashes

P: n/a
Any recommendations for deploying small to middling JavaScript system that
encompasses 10-20 functions ?

The problem is the potential that another other JavaScript system running on
the same page wanting to use the same function name(s) as those in my
system. I don't want to redefine that other systems functions, nor have
mine redefined.

So, is there any sort of 'package' concept

or Should I wrap _all_ my stuff into _one_ class and deploy that. Then only
one identifer has to be considered and changed if namespace clashing would
occur.

Not sure what memory/speed hits might be encountered.

--
Richard A. DeVenezia
Jul 20 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
> Any recommendations for deploying small to middling JavaScript system that
encompasses 10-20 functions ?

The problem is the potential that another other JavaScript system running on
the same page wanting to use the same function name(s) as those in my
system. I don't want to redefine that other systems functions, nor have
mine redefined.

So, is there any sort of 'package' concept

or Should I wrap _all_ my stuff into _one_ class and deploy that. Then only
one identifer has to be considered and changed if namespace clashing would
occur.

Not sure what memory/speed hits might be encountered.


Bundle your packages into objects and avoid global variables. Use jslint to help
identify your global variables.

JavaScript objects are namespaces. Use them to avoid collisions. The performance
hit is negligible.

As you know, JavaScript doesn't have classes. It doesn't need them because its
objects are so flexible.

http://www.crockford.com/javascript/lint.html

Jul 20 '05 #2

P: n/a
Richard A. DeVenezia wrote:
Any recommendations for deploying small to middling JavaScript system that
encompasses 10-20 functions ?

The problem is the potential that another other JavaScript system running on
the same page wanting to use the same function name(s) as those in my
system. I don't want to redefine that other systems functions, nor have
mine redefined.

So, is there any sort of 'package' concept

or Should I wrap _all_ my stuff into _one_ class and deploy that. Then only
one identifer has to be considered and changed if namespace clashing would
occur.


You could create a noop function/constructor just to provide a pseudo
namespace. Something like:

function DeVenezia() {}

And then for each of the 10-20 functions you rewrite as follows:

DeVenezia.function1 = function()
{
//code in here
}

Which you could then call in your code as DeVenezia.function1()

However, object oriented design heuristic #3.2 states: "Do not create
god classes/objects in your system." That's what will more than likely
happen if as you say you "wrap _all_ (your) stuff into _one_ class".
Try organizing your functions by which data they work on, that is what a
class is supposed to be, data and its associated actions.

Jul 20 '05 #3

P: n/a
"Richard A. DeVenezia" <ra******@ix.netcom.com> wrote in message
news:bj************@ID-168040.news.uni-berlin.de...
Any recommendations for deploying small to middling JavaScript
system that encompasses 10-20 functions ?

The problem is the potential that another other JavaScript
system running on the same page wanting to use the same
function name(s) as those in my system. I don't want to
redefine that other systems functions, nor have mine redefined.

So, is there any sort of 'package' concept
JavaScript (ECMA Script) has not "package" concept as part of the
language. A sort of emulation of the concept is possible. How applicable
that could be depends on the actual script.
or Should I wrap _all_ my stuff into _one_ class and deploy
that. Then only one identifer has to be considered and changed
if namespace clashing would occur.
Encapsulating a script into a "class" could easily result in only one
identifier being added to the global name space, and under some
circumstances such a "class" can be totally anonymous. Doing something
in this direction is almost certainly the easiest way of avoiding
namespace conflicts with other scripts. I always take an OO approach to
JavaScript and attempt to encapsulate related functionality.
Not sure what memory/speed hits might be encountered.


Memory use should be nearly equivalent (if done properly). Speed could
be negligibly slower if property accessors are relative to a global
identifier but there is some potential for achieving a performance gain
by using "private" members within the encapsulating structure.

If you want to talk specifics in terms of technique and examples you
will probably have to present some code as a starting point.

Richard.
Jul 20 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.