Sonic Bottle

The home of another wordpress blog.

Namespaces in JavaScript

Did you know? Your JavaScript for your web app might be deployed alongside Javascript files not made by you. WHAT you say, let me explain. You might have a 3rd Party api you connect to and that JavaScript library they provide could clash with your own. To give you an example: You might use a Social API which allows users to post their discussions to a whichever social network is the most popular. This API’s JS library might have a function titled “send()” which could clash with a function you have written to forward an article to an email address titled “send(address, url)“. If you have two functions titled “send()“, the last one to be declared is the function that is called.

function send() {
alert(“We want to call this function”);

function send(address, url) {
alert(“But this is the one that gets called”);


But in Java, C++ that would work you are probably thinking to yourself. That is true, as long as the parameter types were not the same. That is because those languages are what we call “Polymorphic”. They support a feature called “method overloading” allowing you to store multiple methods of the same name in the same class as long as the parameters are different.

class MethodOverrideTest {

public static void main(String[] args) {
MethodOverrideTest test = new MethodOverrideTest();

public String hello(String name) {
return "Hello " + name;

public String hello(String name, String age) {
return "Hello " + name + " you are " + age + " years old.";


Javascript , instead does "method overriding". It allows you to declare a method which has the same name as a method already declared. This means the last method run though the interrupter is the one that will be called no matter if the parameters are different.

So how do we prevent accidental method overriding when combining different javascript libraries together?

This problem exists in other languages and is also fixed by using "namespaces". Namespaces allows you got group method and variable names together under a unique name. Then only the namespaces names must be unique and anything packages instead the namespace only have to be unique to the namespace. But javascript doesn't really have namespaces, instead there are a couple of tricks people employ to fake namespaces. Often namespaces can be the name of the software product, the name of the company or even an amalgamation of the two.

Method 1 - prefix all the methods names

This method has you prefixing the method name of the methods you create with an identifier to your script. So in the case of our example of the 3rd party social api. If the name of the company was "Social Sonic" the submit method could be called this: "socialSonic_send()". This greatly raises the chance of a unique name which will not cause any confliction with other methods on the page. Indeed this method is used by one of the 3rd party libraries I work with.

Critics argue a downside to this method is that it pollutes the Global Namespace and makes the code harder than necessary to read.

Method 2 - enclosing all the methods inside an object

This is method has you creating an object which takes the name of the namespace you are trying to create. Then all subsequent methods you want inside the namespace are added to the prototype of that object.


var nameSpace = nameSpace || {};

nameSpace.helloWorld = function() {
alert("Hello World");

To execute this method you just need to call: "nameSpace.helloWorld()".

This has the advantage that you do not pollute the global namespace as only the name of the namespace has a global scope. It also keeps all of your method calls rather neatly together into one object. But the downside is, it is a little more confusing to first look at than method 1. Also critics argue that is slower to parse that javascript program as you must objects then modify theirs prototypes just to add functions.

This method is the preferred choice by my company in our Web Applications.

  • Javascript is not polymorphic (Method overloading)

  • Javascript does method overriding

  • Be careful about polluting the global namespace.

  • Employ a namespace technique to avoid confliction with other methods.


Further Reading if you are interested

March 12, 2013 Blog , ,

Localisation or Localization

Did you know that there is a small possibility that your Application maybe used by people who are not English speakers who aren’t even in the same country as you. Well this applies
mostly to web(sites/apps), mobile phone applications and larger commercial deployment. But can also come up in areas that will surprise you. With websites your application can
be accessed from all over the world (minus censorship issues of certain countries). This means your user could be anywhere in the world and not speaking the same language as you.

The process of customising an application/site to particular country is called localisation. But why country? This is because different countries have different currencies, languages and ways
to present information. Date and time for example. So we do localisation for each country.

So how do we know how what languages etc.. to use for our user? We know from the locale we get for the user. A locale is a collection of settings about the user. It stores the language,
the currency used and hundreds of other settings.  Using the locale we know what text to display to the user. Gone are the days of hard coding the strings of text you display to the user.
Leave that concept back at your university assignments. In the real world, the text displayed to the user must be dynamic. It must change based upon their locale. They are many
tricks to doing this. PHP has gettext() method with .mo and .po files ,Java has Resource Bundles and Android stores everything in an XML file. My company uses a framework which stores all the text into a large database.

We don’t always use locales decide which translation you wish to you use. Some applications will only target a particular set of people. The project I am currently working on is  an ecommerce site for a retailer in the Uk. They don’t wish to provide translations for other languages since their customer based is English. It is an unnecessary expense to them. But we do use locales in the project. The retailer also sells to Ireland and using the locales we change the currency (and the price) based upon information gathered from the user’s locale.

But even if you do not sell your application on the International market. Your users might still be different nationalities. In London we have the Oyster card. A prepaid electronic travel payment system. Swipe your card over a reader and the fare for your travel is automatically deducted. As you swipe though the reader a digital display records the fare amount to you. But London’s residents are very multi-cultural. The native language of the users isn’t always English. So the language displayed on these readers changes depending on the Locale stored on the card. But the currency doesn’t change, it is still always in £ (Pounds) as that is the only currency in use in England.

Even the word Localisation falls victim to localisation. In America they spell the word with a Z instead of a S, so localisation becomes localization. And so every book and article spells the word the American way. In fact whilst writing this blog entry. LibreOffice is insisting i am spelling it wrong. Marking every damn spelling of localisation with a big red underline.
Well LibreOffice, we invented the language. You just butchered it :p

So the point of this.

  • Hard coded text is bad – Can’t translate hard coded text all that easy

  • Currencies are different but so then is the price.

  • Don’t reinvent the wheel, Frameworks and Languages tend to have systems in built to help you do Localisation. Use them.

  • You will never know when you need Localisation. Your project might suddenly need it, so prepare at the start.



January 23, 2013 Blog , , , , ,