When should I use my own namespace and when should I extend native js objects?

Question

I am in the process of refactoring my code. I'm having trouble deciding on how exactly to implement a couple utility functions I have. Specifically, if certain functions are better off in my personal namespace or extending js Objects directly.

Example of extending native JavaScript Objects

(is this the proper term?).

String.prototype.prettyDate = function(){
  return (this.substr(5,2) + '/' + this.substr(8) + '/' + this.substr(0,4));
}
var myString = "2010-12-27";
//logs 12/27/2010
console.log(myString.prettyDate);

Example using my own namespace

var myNamespace = (function(){
   var my = {};
   my.prettyDate = function ( dateStr ){
      return (dateStr.substr(5,2) + '/' + dateStr.substr(8) + '/' + dateStr.substr(0,4));
   }
return my;
}());
var pretifiedDate = myNamespace.prettyDate('2010-12-27');
//logs 12/27/2010
console.log(pretifiedDate);

Questions to consider

1. When is a utility justifiably inserted into a native JavaScript Object?
2. How can I tell when a utility is better off being in my own namespace?

Answer 1

1. Almost never, because of:

   a/ possible conflicts with other libraries

   b/ extended functions are iterated as properties by in operator, which poses problems unless filtered out by hasOwnProperty (which is not commonly used)

   You can justify this for small, one-script works, but only if you 200% sure that no one, never ever will try to reuse that code somewhere. In such case use it only for functionality which spans more than one module of your code. Extending String with trim() - ok, extending String with prettyDate() - doubtful, extending Object with displayAsPageHeader() - scary.

2. So, almost always.

Answer 2

Watch this video:

• http://ejohn.org/blog/building-a-javascript-library/

John Resig reckons that extending native objects is a recipe for disaster, particularly when a framework or application is likely to grow into something that does far more than was initially intended.

Answer 3

Unfortunately, this question doesn't have a "right" answer. It's a good discussion to have but I fear it'll be closed here. Whether native objects should be extended at all is a subjective debate, and if you accept that it's conditionally okay the answer to "when?" is "depends."

If you have control over its use and whether it will collide with other code, there's really no reason you shouldn't. It can be quite convenient and may reduce code size significantly.

Where there's a real problem with extending native objects is when you have other code running alongside your extension, which may be expecting a different extension in with the same property name, or which may be carelessly using for(var i in obj) without guarding against extensions up the prototype chain.

Answer 4

Ok... i'm not expert at this, but almost never! Things you do are safer inside your namespace. And everything works fine if you follow the module pattern http://www.yuiblog.com/blog/2007/06/12/module-pattern/

However theres are some little tricks that allows us to avoid to overwrite others namespace. per example:

var myNamespace = {}; //my namespace, unsafely written

//Better solution
if(typeof myNamespace === 'undefined'){
    var myNamespace = {};
}

//Shorter solution
var myNamespace = myNamespace || {};

Answer 5

It depends on how much control you have over what code is being run/loaded:

1. If it's all under your control there's nothing wrong with extending built-in objects, JavaScript is designed to be able to do this. The only problem with this is that you can have unexpected issues when two libraries change the same something. Luckily you wouldn't do this to yourself, right?

2. If you don't/can't know, a namespace is much safer albeit clunky and verbose. This is always safer.

Personally, I prefer the second option because I dislike overly verbose code and namespaces look funny.