<pre data-sub="prettyprint:_">
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml" >
        <head id="Head1" runat="server">
        <title>ASP.NET AJAX Namespaces</title>
        <script type="text/javascript">
        function pageLoad(sender, args) {
        Type.registerNamespace('Wrox.ASPAJAX.Samples');
        alert(Type.isNamespace(Wrox.ASPAJAX)); //displays
        alert(Type.isNamespace(Wrox.ASPAJAX.Samples)); //displays
        var namespaces = Type.getRootNamespaces();
        for(var i = 0, length = namespaces.length; i < length; i++) {
        alert(namespaces[i].getName()); //displays     }}
        </script>
        </head><body>
        <form id="form1" runat="server">
        <asp:ScriptManager runat="server" ID="scriptManager1" />
        <div>    </div>
        </form></body></html>
        </pre>


        <p>
        The call to Type.registerNamespace creates three different objects: Wrox, ASPAJAX, and Samples. The Wrox object contains the ASPAJAX object, which in turn contains the Samples object. The objects all carry some metadata so the type system can identify them as namespaces and use them to hold any other objects that are added to the namespace.

        The Type.isNamespace function returns a Boolean. The code didn’t create an Album namespace, so for that check, it returns false. The set of global namespaces is retrieved by calling Type.getRootnamespaces. Looping through the returned array and calling getName on each reveals that, in addition to the new Wrox namespace, there is also a Sys namespace. It contains the AJAX Library functionality.

        Although doing so is not technically required, I recommend using namespaces to organize your own code, even if just to avoid cluttering up the global namespace. Because JavaScript is an interpreter language, the operation of resolving names is expensive. Every time you call a function, the JavaScript engine has to figure out where the code lives. Resolving variables also involves searching the current scope and containing scopes until the reference is resolved. The more global objects you have, the more expensive it is for the script engine to access them. Namespace objects also allow navigating to classes in the hierarchy more readily than would happen in a flat global arrangement. Thus, namespaces offer a performance benefit as well as providing a programmer convenience for grouping functionality. Namespaces by themselves, however, are not much use until your create classes in them that will provide useful functionality.


        </p>