Description:
------------
###
# Introduction
###
This document is an RFC for adding a small patch to the zend engine to allow for native singleton classes.  The problem 
is that currently theres no clean way to implement singleton classes in user-land over the entirety of a project.

Singleton classes are beneficial because:

- Removes the overhead of having multiple instances of the one object when there is no need
- Allows you to keep the objects state rather than always starting from an initial state. 
- They provide namespaces with the benefits of polymorphism (eg - singleton classes can override / inherit from each other)

Throughout this document, I will use an example of a singleton class "members" which acts as an interface to a database table.  
This class can save and load members from this database table simply by calling the following methods in this class.

members::get($member_id) Loads a member from a member id and returns an associative array with info about that member
members::save($member) Saves a member to the database from an array of properties about that member

With the recent phase of tiered and service oriented architecture, the need for Singleton has become more and more apparent.




###
# Singleton in php5
###
In the past, I have implemented Singleton two different ways.  Both of these have problems.


# Method 1:
The first method involves having a public static getInstance method in every singleton class.  This sucks because you
need to manually copy and paste it into every singleton class you make.  Using a singleton class in this way is also confusing
for novice programmers. Eg:

<?php

class members
{
	static public function getInstance()
	{
		static $object = null;
		
		if($object)
		{
			return $object;
		}
		
		$object = new members();
		return $object;
	}
	
	/**
	 * Returns a member from the database based on their id
	 */
	function get($id)
	{
		// ...
	}
	
	// save method etc...
}

// Usage
$arrMember = members::getInstance()->get(49);
$arrMember['member_f_name'] = 'Scott';
members::getInstance()->save($arrMember);

?>



# Method 2:
This method involves an associative array of class names to their instances, probably via a helper function similar to this.

<?php

class members
{
	/**
	 * Returns a member from the database based on their id
	 */
	function get($id)
	{
		// ...
	}
	
	// save method etc...
}

/**
 * Returns an instance of a singleton class from its class name
 */
function getInstance($strClass)
{
	static $objects = array();
	
	if(!isset($objects[$strClass]))
	{
		return $objects[$strClass];
	}
	
	$objects[$strClass] = new members();
	return $objects[$strClass];
}

// Usage
$arrMember = getInstance('members')->get(49);
$arrMember['member_f_name'] = 'Scott';
getInstance('members')->save($arrMember);

?>

This sucks because its slow, confusing for novices, and IDEs never pick up the class for code hinting.




###
# Proposed new functionality
###

I propose that singleton classes become a native part of the php language by adding the "singleton" class modifier T_SINGLETON.

I don't know if native singleton classes have been implemented in a language before.  Most other languages eg - C++
you can use template classes or generics to implement a clean singleton.

The zend engine could feature a hash table and store the instances of objects.

An example of the new way of using singleton classes would be:

<?php

/**
 * A class for saving / retreiving members from a database
 */
singleton class members extends dataadapter
{
	/**
	 * Returns a member from the database based on their id
	 */
	function get($id)
	{
		// ...
	}
	
	// save method etc...
}


// Usage
$arrMember = members->get(49);
members->save($arrMember);

?>


###
# Edge cases / got-cha's
###
Some investigation will have to be performed as to how inheritence will work with singletons.

Eg 
- Never have singleton abstract classes?

- What happens when $members = new members() is called
-- I say an exception being thrown and a suggestion to remove "new"

- Is it ok to go $members = members; ?
-- I'd say yes

- Singleton constructors should not have parameters

- Perhaps a new function singleton_getobjects needs to be added to enable access to the internal hash table 

- Dereferencing a non-singleton class should produce the same error