Dealing with possible namespace clashes

[Richard A. DeVenezia]

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.

 

[Douglas Crockford]

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

 

[George M Jempty]

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.

 

[Richard Cornford]

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.

 

[Lasse Reichstein Nielsen]

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

no need to make it a function. A plain object will do. All you use
it for is a namespace.

Try organizing your functions by which data they work on, that is
what a class is supposed to be, data and its associated actions.

No, that is what an object is supposed to be. State and behavior. Data
and actions. Classes just make a nice abstraction for objects.

Javascript doesn't have classes. It only has objects.

/L

 

[George M Jempty]

no need to make it a function. A plain object will do. All you use
it for is a namespace.

For which? Because I've got two functions going on in my suggestion
I presume you mean a plain object in place of the first function I
suggest, the noop DeVenezia(). And when you say a plain object, are you
suggesting using the new Object() constructor? Or do you just mean
declaring a plain variable? Because it would be an object, since as you
point out below everything is an object in Javascript.

No, that is what an object is supposed to be. State and behavior. Data
and actions. Classes just make a nice abstraction for objects.

Javascript doesn't have classes. It only has objects.

What about primitives? Otherwise of course you are correct. I just
keep falling back on the concept of classes because of the way
function() can be used as an object constructor.

G

 

[Lasse Reichstein Nielsen]

For which? Because I've got two functions going on in my suggestion
I presume you mean a plain object in place of the first function I
suggest, the noop DeVenezia().

Correct. I wasn't being too specific there

And when you say a plain object, are
you suggesting using the new Object() constructor?

Yes. That, or the object literal "{}".

Because it would be an object, since
as you point out below everything is an object in Javascript.

Not everything is an object, although many things are.
Numbers, strings, booleans, null and undefined are not objects,
although they are sometimes silently converted to objects.

I meant "only objects" as opposed to both objects and classes.
There are non-objects in the language too, the primitive types
mentioned above.

What about primitives? Otherwise of course you are correct. I just
keep falling back on the concept of classes because of the way
function() can be used as an object constructor.

Classes in typical object oriented languages are an abstract concept
used to generalize over a number of similar objects. They are the
blueprint that new objects are made after (often with the "new"
keyword).

In Javascript, new objects are created by functions, so it is obvious
to think of the functions as representing a class. It is a dangerous
simplification, though. Two objects created from the same function
doesn't need to have anything in common. I might have changed
the prototype object completely between the two.
---
function Foo(){};
Foo.prototype = {x:4,y:5};
var foo1 = new Foo();
Foo.prototype = [1,6,8,9];
var foo2 = new Foo();
---
These two objects, foo1 and foo2, have nothing in commen except
the function used to instantiate them, and there is noting in
the objects that reflect this connection. The objects could just
as well have come from completely different constructors.

Javascript has no classes, prototypes instead of inheritance, and
dynamically extensible objects. It is closer to Smalltalk or Self,
than to Java.

/L

 

[Richard Cornford]

For which? Because I've got two functions going on in my
suggestion I presume you mean a plain object in place
of the first function I suggest, the noop DeVenezia(). And
when you say a plain object, are you suggesting using the
new Object() constructor? Or do you just mean declaring
a plain variable? Because it would be an object, since as
you point out below everything is an object in Javascript.

<snip>

var anyName = {
doThis:function(){
...
},
doThat:function(){
...
},
doTheOther:function(){
...
}
};

Leaving an object with 3 members that are functions and can be called
as - anyName.doThis(); - etc. Obviously this object can have any number
of functions and other properties holding primitives to replace global
variables. The functions within the object can reference other functions
and properties of the object using the - this - keyword instead of -
anyName.

Richard.