codeigniter's super object

I hope everybody have seen & get_instance variable while working in codeigniter. I searched and trying
to find out how codeigniter builds super object and how it works internally. Hope we will enjoying it.

CI works by building one 'super-object', it runs  whole program as one big object, in order to eliminate scoping issues. When we start CI, a complex chain of events occurs.  If we set CI installation to create a log, we'll see something like this:-

    1 DEBUG - 2006-10-03 08:56:39 --> Config Class Initialized
    2 DEBUG - 2006-10-03 08:56:39 --> No URI present. Default controller  set.
    3 DEBUG - 2006-10-03 08:56:39 --> Router Class Initialized
    4 DEBUG - 2006-10-03 08:56:39 --> Output Class Initialized
    5 DEBUG - 2006-10-03 08:56:39 --> Input Class Initialized
    6 DEBUG - 2006-10-03 08:56:39 --> Global POST and COOKIE data sanitized
    7 DEBUG - 2006-10-03 08:56:39 --> URI Class Initialized
    8 DEBUG - 2006-10-03 08:56:39 --> Language Class Initialized
    9 DEBUG - 2006-10-03 08:56:39 --> Loader Class Initialized
    10 DEBUG - 2006-10-03 08:56:39 --> Controller Class Initialized
    11 DEBUG - 2006-10-03 08:56:39 --> Helpers loaded: security
    12 DEBUG - 2006-10-03 08:56:40 --> Scripts loaded: errors
    13 DEBUG - 2006-10-03 08:56:40 --> Scripts loaded: boilerplate
    14 DEBUG - 2006-10-03 08:56:40 --> Helpers loaded: url
    15 DEBUG - 2006-10-03 08:56:40 --> Database Driver Class Initialized
    16 DEBUG - 2006-10-03 08:56:40 --> Model Class Initialized

each time a page request is received over the Internet , CI goes through the same procedure.
We can trace the log through the CI files:-

The index.php file receives a page request. The URL may indicate which controller is required, if not, CI has a default controller (line 2). Index.php makes some basic checks and calls the codeigniter.php file.
  
The codeigniter.php file instantiates the Config, Router, Input, URL, (etc.) classes (lines 1, and 3 to 9). These are called the 'base' classes: we rarely interact directly with them, but they underlie almost everything CI does.
  
codeigniter.php tests to see which version of PHP it is running on, and calls Base4 or Base5 (/codeigniter/Base4(or 5).php). These create a 'singleton' object: one which ensures that a class has only one instance. Each has a public &get_instance() function. Note the &:, this is assignment by reference. So if we assign to the &get_instance() method, it assigns to the single running instance of the class. In other words, it points we to the same pigeonhole. So, instead of setting up lots of new objects, we are starting to build up one 'super-object', which contains everything related to the framework.
  
After a security check, codeigniter.php instantiates the controller that was requested, or a default controller (line 10).

The new class is called $CI. The function specified in the URL (or a default) is then called, and life as we know it starts to wake up and happen. Depending on what we wrote in   controller, CI will then initialize any other classes we need, and 'include' functional scripts we asked for. So in the log above, the model class is initialized. (line 16)

    class my_new_class{
var $base;
My_new_class()
{
   $obj =& get_instance();
   // geolocation code here, returning a value through a switch statement
   //this value is assigned to $local_url
   $this->base = $obj->config->item('base_url);
   $this->base .= $local_url;
}
    }

We've looked at the way CI builds up one 'super-object' to make sure that all the methods and variables we need are automatically available without having to manage them and worry about their scope.

CI makes extensive use of assignment by reference, instantiating one class after another and linking them all together so that we can access them through the 'super-class'. Most of the time, we don't need to know what the 'super-class' is doing, provided that we use CI's 'arrow' notation correctly. We've also looked at how we can write   own classes and still have access to the CI framework.