Miles Johnson

RFC proposal for getters and setters

If you haven't been following the PHP development lately, then you have been missing out. Recently, there was a vote on the PHP mailing lists about adding short syntax for arrays (ala Javascript), yet the devs vote against it with childish excuses. And then there was this one guy who forked the PHP project and patched it with speed improvements and features the users have been wanting (which I completely agree with). You can also view the PHP RFC Wiki on the list of *possible* features and the ones that were denied. As you can see, there is much happening in the PHP community, but nothing to show for it (yet).

However, my post today will be on the RFC suggestion for built in getters/setters. To keep it blunt, I really dislike the C# approach... it's, just not very PHP. Just seems odd to have floating curly blocks with a "get" and "set" in it, with no real defined scope block. On top of that, the "property" keyword is way too complicated for what it is trying to achieve. The one thing I do agree with though, is the readonly modifier. My suggestion is loosely based on the Traceur Compiler by Google syntax (they use get/set keywords instead of function, within the class).

class FooBar {

	public $value;

	protected readonly $_readOnly;
	
	protected static readonly $_static;

	public get value() {
		return $this->value;
	}

	final public set value($value) {
		$this->value = $value;
	}

	public get readOnly() {
		return $this->_readOnly;
	}
	
	public static get static() {
		return self::$_static;
	}

	public function noop() {
		return;
	}

}

Admittedly, my suggestion is a bit more verbose than the C# variant, and pretty similar to regular getValue() and setValue() methods, but there are a few key differences.

Method Naming

Technically, are they still considered methods? Regardless, when you are writing getters and setters, you should use the words "get" or "set" in place of "function". This dictates to the class that these methods should be used anytime a property is being read or written to. On top of this functionality, the visibility modifiers are in effect (public, protected, private). This allows you to write to protected properties using a public setter, or reading from private properties with a protected getter (while in the class scope of course). Final and static keywords work exactly the same as well. Below is a quick example.

$foo = new FooBar();

$foo->value = 'setter'; // calls set::value()
$foo->readOnly = 'readonly'; // throws an error/exception
FooBar::$static = 'static'; // throws an error/exception

echo $foo->value; // calls get::value()
echo $foo->readOnly; // calls get::readOnly()
echo FooBar::$static; // calls get::static() statically

Getters and setters are not required, but when implemented, they are automatically triggered. If a property is public, without a getter/setter, then getting/setting a value works like it normally would. The major difference with this proposal is allowing the getting/setting of non-public properties, and never having to write getValue() or setValue() (you just modify the property directly like the example above).

Read Only

One of the features within the original proposal that I did like, was the readonly keyword. This keyword can be applied to any class property to set it into a read-only state, which basically disallows the use of a set method. It also disallows setting a value to the property directly, using the old functionality. But this sounds like the final keyword right? Technically yes, the major difference is that you can overwrite a readonly value in a sub-class, and not with a final.

Abstract and Interfaces

These could also be used with abstract classes and interfaces, like so.

interface FooBar {
	public get value();
	public set value();
}

abstract class FooBar {
	protected $value;
	
	abstract protected get value();
	abstract protected set value();
}

Now this is just a personal preference and style, and is something I have been thinking about lately (I have ideas for other RFCs as well), so don't expect this to actually happen! I also didn't get too in depth, for example, when are magic methods called during this process? I will leave those out unless for some odd reason this makes it in (heh). Let me know what you think!

Old School PHP Scripts: Numword, the number to word converter

The Numword class (via Github) will rarely find a use, but its creation was primarily for fun. A friend of mine asked me if there was a PHP function that will turn a number into its word equivalent (example, 100 becomes one-hundred). As none existed, I felt like this would be a fun task to attempt, and so the Numword class was born. Numword supports the basic range of numbers and the ability to convert up to centillion (which is mind blowingly large).

The easiest way to convert a number is to use the single() method. This method accepts a single number argument and returns the word equivalent. You may also use the multiple() method which accepts an array of numbers. Do note however, that large numbers must be passed as a string, else it will blow up because of PHPs 32 bit integers.

// one-thousand, two-hundred thirty-four
Numword::single(1234);

// eight-billion, two-hundred thirty-four-million, seven-hundred eighty-thousand, two-hundred thirty-four
Numword::single('8234780234');

Some other convenient methods are block() and currency(). The block() method will parse out any numbers within a string of text, and convert them. While the currency() method is self explanatory, it converts currency.

// I am twenty-five years, fifteen days and sixty-two minutes years old.
Numword::block('I am 25 years, 15 days and 62 minutes years old.');

// one-thousand, three-hundred thirty-seven dollar(s) & fifteen cent(s)
Numword::currency('$1,337.15');

Awesome right? Furthermore, the currency() method is rather smart, in that it parses out the dollar sign, commas, and periods depending on the current locale based on setlocale(). You can also translate the strings used in currency() by passing an array as the second argument. But before we do that, lets go over translating the whole class.

Translating the strings in Numword is extremely easy, but also tedious. If you only need to translate for a single language, then you can overwrite the static properties. If you need to translate for multiple languages (user language selection system), then you will still need to overwrite the properties, but create some kind of system to know which language to use and when (possibly via includes). Here's an example translation of German; zero through nine respectively.

Numword::$digits = array('null', 'eins', 'zwei', 'drei', 'vier', 'fünf', 'sechs', 'sieben', 'acht', 'neun');

And to translate the currency strings, you can do something like:

Numword::currency('£48,530.38', array('dollar' => 'pound(s)', 'cent' => 'pence'));

Numword isn't as extensible as I would like, but since it is merely a fun project, the need for heavy translation and locale awareness settings aren't needed. You can always base your own class on Numword :). Hope you enjoyed!

Naming your cache keys

Everyone caches, that's a pretty well known fact. However, the problem I always seemed to have was how to properly name my cache keys. After much trial and tribulation, I believe I have found a great way to properly name cache keys. To make things easy, my keys usually follow this format.

<model|table>__<function|method>[-<params>]

To clear up some confusion, it goes as follows. The first word of your cache key should be your model name (or database table name), as most cached data relates to a database query result. The model name is followed by a double underscore, which is then followed by the function/method name (which helps to identify exactly where the cache is set), which is then followed by multiple parameters (optional). Here's a quick example:

public function getUserProfile($id) {
	$cacheKey = __CLASS__ .'__'. __FUNCTION__ .'-'. $id;

	// Check the cache or query the database
	// Cache the query result with the key
	// Return the result
}

The $cacheKey above would become: User__getUserProfile-1337, assuming the user's ID is 1337. Pretty easy right? Besides the verbosity that it takes to write these constants, it works rather well (unless you want to write the method and class manually). You may also have noticed that I used __FUNCTION__ over __METHOD__ -- this was on purpose. The main reasoning is that __METHOD__ returns the class and method name, like User::getUserProfile, while __FUNCTION__ just returns the method name.

The example above will work in most cases, but there are other cases where something more creative is needed. The main difficulty is how to deal with array'd options. There are a few ways of dealing with that, the first is checking to see if an ID or limit is present, if so, use that as the unique value. If none of the options in the array are unique, you can implode/serialize the array and run an md5() on the string to create a unique value.

User::getTotalActive();
// User__getTotalActive

Topic::getPopularTopics($limit);
// Topic__getPopularTopics-15

Forum::getLatestActivity($id, $limit);
// Forum__getLatestActivity-1-15

Post::getAllByUser(array('user_id' => $user_id, 'limit' => $limit));
// Post__getAllByUser-1-15

User::searchUsers(array('orderBy' => 'username', 'orderDir' => 'DESC'));
// User__searchUsers-fcff339541b2240017e8d8b697b50f8b

In most cases an ID or query limit can be used as a unique identifier. If you have another way that you name your cache keys or an example where creating the key can be difficult, be sure to tell us about it!

How useful is the new ?: operator?

As with everyone else excited about PHP 5.3, I was extremely looking forward to developing in it. I was especially excited to use the new shorthand ternary operator (?:). This would remove the redundant middle expression of returning the variable, and instead would return itself if it evaluated to true. But after much testing and trying to implement it in interesting ways, the shorthand ternary just isn't as useful as you would hope. The primary problem is the left-most expression must evaluate to true or false, which isn't possible with the shorthand. Below is my test case.

error_reporting(E_ALL | E_STRICT);

class Ternary {
	private $__data = array('key' => 'value');

	public function get($key, $default = null) {
		return $this->__data[$key] ?: $default;
	}
}

$test = new Ternary();

var_dump($test->get('key')); echo '<br>';
var_dump($test->get('test')); echo '<br>';
var_dump($test->get('')); echo '<br>';
var_dump($test->get(false)); echo '<br>';
var_dump($test->get(null)); echo '<br>';

This test works for the most part, the value or null is always returned. However, the problem is that this technique throws notice errors; here is the result after running the test. You can easily avoid this by turning of notice errors, but that's bad practice.

string(5) "value"

Notice: Undefined index: test in C:\xampp\htdocs\scripts\index.php on line 9
NULL

Notice: Undefined index: in C:\xampp\htdocs\scripts\index.php on line 9
NULL

Notice: Undefined offset: 0 in C:\xampp\htdocs\scripts\index.php on line 9
NULL

Notice: Undefined index: in C:\xampp\htdocs\scripts\index.php on line 9
NULL

I was hoping the new shorthand ternary would internally run an isset() and evaluate automatically, but it looks like it does not. So now we are still stuck with the old verbose way of doing things.

return isset($this->__data[$key]) ? $this->__data[$key] : $default;

Is there a reason why the PHP devs chose not to run an isset automatically? Or am I doing something wrong here? More information on this would be helpful, because I believe the operator would be multitudes more useful if it worked like I suggested.

Using Closures as callbacks within loops

In jQuery (and other Javascript frameworks) it is quite common to use closures (I refer to them as callback functions) to loop over arrays or objects. Even though it's a slow process and is much more efficient to use the built-in for loop, it got me thinking. Why not try and use the new Closure class in PHP 5.3 and see how well it performs within a loop? Suffice to say, I got some really really interesting results. Before I get into the details, here is the test script I wrote (the Benchmark class is merely a class I have written in the past).

<?php $data = range(0, 1000);
$clean = array();

public function loop($array, Closure $closure) {
	if (!empty($array)) {
		foreach ($array as $key => $value) {
			$closure($key, $value);
		}
	}
}

Benchmark::start('loop');

foreach ($data as $key => $value) {
	$clean[$key] = $value;
}

loop($data, function($key, $value) {
	$clean[$key] = $value;
});

Benchmark::stop('loop');
echo Benchmark::display('loop'); ?>

I didn't get too in depth with my test cases and simply used Firefox and page refresh to get my results. I am running PHP 5.3.1 on a Windows 7 XAMPP installation with Apache and no caching. For benchmarking I was using microtime(true) and memory_get_usage().

I began testing with 4 different cases, each of which that changed the size of the $data array. I started with 1000 iterations, then 5000, then 10000 and lastly 100000. I would comment out the foreach/loop sections and run them one at a time (of course), and ran each test about 5 times to gather an average. Here are the results.

foreach:
1000	Time: 0.0010 / Memory: 137128 (Max: 689160)
5000	Time: 0.0052 / Memory: 706488 (Max: 1258528)
10000	Time: 0.0097 / Memory: 1412048 (Max: 1964120)
100000	Time: 0.0545 / Memory: 13849568 (Max: 14401656)

closure:
1000	Time: 0.0027 / Memory: 84984 (Max: 688832)
5000	Time: 0.0144 / Memory: 433672 (Max: 1258192)
10000	Time: 0.0267 / Memory: 866448 (Max: 1963744)
100000	Time: 0.1223 / Memory: 8525216 (Max: 14401256)

The first thing you will notice is the time it took to interpret the page. On average using a closure as a callback within a loop will take 2-3x longer to process. However, the interesting thing is that the memory usage is around 40% smaller (using more allocated memory) while using a closure than doing a foreach, yet the max allocated is nearly identical. I knew what the outcome would be before I even started it -- Javascript closures are the same way. Regardless it was a fun experiment and if anyone knows more about this, please shed some light on this topic for the rest of us!

But in closing I can sadly say, that no, you should not be using a closure for looping, just stick to the old fashion tried and true foreach or for loop.

Converting a SimpleXML object to an array

If you have been following my Twitter, you would of heard me complaining about converting a SimpleXML object into an array. I am still having that problem, so if you can get it working correctly (my test so far below), I would be greatly appreciative. If you have never used the SimpleXML object, it can be quite awesome when actually reading an XML document - but once it comes to converting it to something else, it comes straight from the darkest depths of hell. Every property of the object, is also a SimpleXML object, so on and so forth. Each property/object has a method children(), which returns more properties, or attributes() which returns attributes; weirdly enough, children() also return attributes. Furthermore, you can't just echo the object out to get a value, you have to turn it into a string. You can see where this can get quite difficult and confusing, as it always spits out data your not expecting.

After countless hours, I was able to get it to properly convert to an array... about 95% of the time... while keeping attributes and parent/children hierarchy. The only scenario where it doesn't convert properly, is when you have nodes within a node that has attributes (which is kind of rare in my opinion). Here's a small little example:

// Works just fine
<root>
	<node foo="bar">I'm a node!</node>
</root>

// Does not work
<root>
	<node foo="bar">
		<childNode>I'm here to make your life miserable!</childNode>
		<childNode>Me too!</childNode>
	</node>
</root>

Besides that little instance, I am able to properly turn an XML document with attributes, and multiple nodes with the same name, all into a perfectly replicated array. Here is the code I wrote to achieve such an amazing task (sarcasm).

/**
 * Convert a SimpleXML object into an array (last resort).
 *
 * @access public
 * @param object $xml
 * @param boolean $root - Should we append the root node into the array
 * @return array
 */
public function xmlToArray($xml, $root = true) {
	if (!$xml->children()) {
		return (string)$xml;
	}

	$array = array();
	foreach ($xml->children() as $element => $node) {
		$totalElement = count($xml->{$element});
		
		if (!isset($array[$element])) {
			$array[$element] = "";
		}

		// Has attributes
		if ($attributes = $node->attributes()) {
			$data = array(
				'attributes' => array(),
				'value' => (count($node) > 0) ? xmlToArray($node, false) : (string)$node
				// 'value' => (string)$node (old code)
			);

			foreach ($attributes as $attr => $value) {
				$data['attributes'][$attr] = (string)$value;
			}

			if ($totalElement > 1) {
				$array[$element][] = $data;
			} else {
				$array[$element] = $data;
			}

		// Just a value
		} else {
			if ($totalElement > 1) {
				$array[$element][] = xmlToArray($node, false);
			} else {
				$array[$element] = xmlToArray($node, false);
			}
		}
	}

	if ($root) {
		return array($xml->getName() => $array);
	} else {
		return $array;
	}
}

I know exactly where the problem resides also. Its the value index of the $data array. (The little bastard below).

$data = array('attributes' => array(), 'value' => (string)$node);

// Should be
$data = array('attributes' => array(), 'value' => xmlToArray($node, false));

A simple fix right? Nope! When you do that, it totally breaks... for some reason. The first line of the function (!$xml->children()) gets passed since the element passed does have children, since it has attributes; now I can never understand why attributes count as children when you have attributes(). I tried many different conditionals to get it working, I tried unsetting the attributes (but can't determine the property), and all these other routes... but to no avail. But I digress, seeing as how it works 95% of the time, and the case it doesn't work isn't used that much. However, if you can figure it out, I will be in your debt forever.

Minimalistic approach to class getters and setters

Getters and Setters are the backbone of many PHP classes (or any programming language class), as they allow you to alter and retrieve class properties during runtime. Many well thought and powerful scripts and frameworks make use of Getters and Setters, but is there a thing as too much? Or are there better and easier alternatives? (To make it easier on me to type, and you to read, I will refer to Getters and Setters as GnS from now on.)

By now everyone should know of the Zend Framework. It's a highly customizable and robust system built with multiple components. Zend follows the pure OOP paradigm in which most, if not all classes have an abstract, an interface, and tons of GnS. For a beginner, this might look like a huge cluster of code, as well as being very large in its documentation. But for an advanced user, it could be a god send. Personally, I find Zend's use of GnS to be too much, as it can easily be trimmed down and packaged accordingly.

Before we begin, I want to outline when and how GnS should be used. GnS should be used to alter protected properties only. Why protected you ask? If a property was public, then you can just alter the property manually without the need for a median method (unless of course the method does some manipulation on the argument). If a property is private, then that property should not be altered at all during runtime, as it is data specifically generated/built by the class internally. So that leaves protected properties to act as our configurable properties.

In a typical class, when dealing with the property $_name, you would have a method getName() and setName(). Now imagine you have a class with 15+ properties; you will immediately begin to realize the scale and amount of code required to do GnS. That's where our little friends __set(), __get() and __isset() come in handy. We can easily scale down the code from 30 methods (15 for getting, 15 for setting) to 3. Take the following before and after classes:

// Using individual methods
class User {
    protected $_name;
    protected $_email;

    public function getName() {
        return $this->_name;
    }

    public function setName($value) {
        $this->_name = $value;
    }

    public function getEmail() {
        return $this->_email;
    }

    public function setEmail($value) {
        $this->_email = $value;
    }
}

// Using magic methods
class User {
    protected $_name;
    protected $_email;

    public function __get($property) {
        return (isset($this->{'_'. $property}) ? $this->{'_'. $property} : null);
    }

    public function __set($property, $value) {
        if (isset($this->{'_'. $property})) {
            $this->{'_'. $property} = $value;
        }
    }

    public function __isset($property) {
        return isset($this->{'_'. $property});
    }
}

Does that not look a lot easier? Sure the code looks a bit "hacky", but its perfectly usable and valid code. Of course, there are a few downsides related to this approach. For example, you may want to format a string before assigning it within setName(). With the magic methods you can not do so. But that doesn't stop you from creating a setName(), along side using the magic methods. Furthermore, the get syntax is different; you simply call the property (assuming there is no $name that conflicts with $_name).

// Using individual methods
$name = $User->getName();
$User->setName('Miles');

// Using magic methods
$name = $User->name;
$User->name = 'Miles';

// Times when a set method is needed
public function setName($name) {
    $this->_name = ucall($name);
}

I would like to take this a step further, as I still believe that this is too "cluttered". The next approach solves the problem of conflicting property names, as well as reducing the code required. The approach is straight forward; simply create a global $_config (or $_data, what ever suits you) property that will deal with all the getting and setting of data.

class User {
    protected $_config = array(
        'name' => null,
        'email' => null
    );

    public function __get($property) {
        return (isset($this->_config[$property]) ? $this->_config[$property] : null);
    }

    public function __set($property, $value) {
        if (isset($this->_config[$property])) {
            $this->_config[$property] = $value;
        }
    }

    public function __isset($property) {
        return isset($this->_config[$property]);
    }
}

In the end, it really boils down to the architecture of your application, and your personal coding preferences. Each approach has its pro's and con's, but the best solution (in my mind) is combining them. You would begin by creating the global $_config property, and building the magic methods. If you ever need to customize a get or set, then you create a specific method for it.

PHP Pro Tip: Don't close your PHP documents with ?>

Recently on my Twitter I mentioned this exact tip, "PHP Pro Tip: Don't close your PHP documents with ?>.", and got many responses asking why or if it's possible. I will briefly explain the benefits of this technique and when it applies. Many assumed I meant that you should never close your PHP scopes with ?>, but that's not the case, I was merely stating that the closing tag (at the very very bottom of your PHP file) does not need to be there.

If you are within a template file that has multiple opening and closing PHP tags, then of course it would be required to close those. If you have a PHP class or file that's purely PHP and consists of no front-end markup, then the closing tag at the bottom of the page is optional. It even says so in the official PHP.net documentation.

The closing tag of a PHP block at the end of a file is optional, and in some cases omitting it is helpful when using include() or require(), so unwanted white space will not occur at the end of files, and you will still be able to add headers to the response later. It is also handy if you use output buffering, and would not like to see added unwanted white space at the end of the parts generated by the included files.

Now onto the benefits to this technique. The main benefit is that it solves the "unwanted white space" at the beginning of the next document, causing it to error out and spew HTTP headers. It does so by keeping the PHP scope open at the end of the script, and allowing included files to continue within the scope and not fail. It also means you don't have to spend the time making sure there is no white space or new lines at the end of your files.

Very handy if you ask me. So just a heads up with a little tip. Enjoy :]

Why pure OOP, just for the sake of doing pure OOP

Lately all I have seen is the "Pure OOP is the way to go mentality" without much reasons to back up why its beneficial. I write OOP code, but I don't write overly verbose, bloated and cluttered OOP code either. I attend Zendcon, I have my PHP certification, I read PHP blogs on a daily basis, I have had multiple OOP discussions with other developers, but in the end I still ask the question, "Why do you spend so much time writing and separating your objects? When in the end its unnecessary as you are not extending them in the future anyways."

Before I begin, I want to do a quick review on how I got onto this topic. It started a few days ago when Brandon Savage posted his article Why Great Development Tools Don't Seem To Be Written In PHP, in which I agreed with him. Further into the comments, many users mentioned the PHP bug tracker Arbit Tracker. After downloading the source and browsing the code, I came to the following conclusion and posted this comment on Brandons entry:

After looking at Arbit... Why do people always need to use SO MANY files and classes to do such a basic task? Its unbelievable how bloated some projects can get. There is a thing with being to modular.

Just take a guess at how many files are required for a basic issue tracker... just guess. There are 2,077 files and 402 folders, and remember this is still an alpha version so that can grow even larger. Basically my first reaction was "Seriously? Do we really need all these files and classes to create a simple and basic bug/issue tracker". I have nothing against Arbit, nor the developers (They know there PHP for sure), but there is something terrible wrong about this in my opinion. This is a "3rd party script that is installable on a users machine", yet looks like a full blown framework and application. When I download a script to install on my machine, I want it to be lightweight, usable, easy and customizable. I find something really wrong about this when it takes this many classes to do such a basic task, and on top of that it requires multiple dependencies like EZ Components and CouchDB (and from what I could find, this wasn't even in the source! Now add more files into the final count). After my comment everyone seemed to post the same response: "Well of course, its a pure OOP project", and "This is what happens when you do it in true OOP", and "Nothing beats an OOP setup!".

I mentioned that a project does not need an abstract, an interface or even an exception for every class in its system, and I received this lovely little response.

If you want superior software then you use the standard and that (just) happens to be object oriented methodologies.

Drop object oriented methodologies and you drop way too many other natural benefits to software development; so enough of your bullsh*t okay?

I find this response laughable. Please tell me what those natural benefits are? To expand on classes if you want to customize it or create your own? To extend them even further? Dependency Injection? Multiple other reasons... You get my point. That's what abstract and interfaces are for. So why create them when YOU KNOW you will never extend them further, or even bother creating child classes. It seems everyone is in this mentality of "Ill do pure OOP just for the sake of doing OOP."

I can see when abstract and interfaces are required, like Zend Framework for example, but even then its overkill. Very rarely does anyone ever extend or use the abstract/interfaces in Zend. I've worked at many jobs and on many projects that utilized Zend, and have even worked with individuals that do the "Pure OOP" approach, and still I have not seen them extend objects like they are supposed to be, or use OOP to its fullest. I can only recall very few instances when people actually extended the objects, and it was primarily for Auth classes to customize to fit their application.

Another thing I dislike about pure OOP approaches is the amount of code you have to write to do such basic tasks. Take for example the routing components of Zend:

$this->getRouter()->addRoute('user', new Zend_Controller_Router_Route('user/:username', array('controller' => 'user', 'action' => 'info')));

I mean, whats so difficult about the following approach (below)? Why do you need to create a whole new object as an argument, when the object is just going to be a toArray() anyways and set as a property? Oh I know, its because you want to maybe use a Route_Regex class, or a Route_Hostname class. Now my question is, why would those even need to be their own class? Because they each do a different purpose and have their own methods that overwrite the abstracts? I guess that's where we disagree then. I honestly don't see a reason why these should be "split" up. The Router should manage all routes and package the class appropriately. Breaking up the classes isn't being "Pure OOP", its just being overly modular.

Say and think what you wish, but there's nothing wrong with the following piece of code either. But you'll probably find something wrong with static methods as well, seeing as how it doesn't add any OOP functionality.

Router::addRoute('user', 'user/:username', array('controller' => 'user', 'action' => 'info'));

I also have a problem with the amount of getters and setters I see everywhere. Have you not heard of __call, __get, __set, __isset, or __unset? But I digress, that topic is for another entry at another time.

I'll stop ranting now, its a matter of preference. Id also like to note that CakePHP (a non-pure OOP approach, but still OOP) has the same functionality and customization as Zend and Symfony (both pure OOP approaches). So why do you think Cake is inferior to the others? Personally, I think it has more beneficial and useful functionality.

The awesomeness of 5.3 Namespaces

If you haven't heard of Namespaces, or even PHP 5.3, you need to stop living under a rock. I've had quite a bit of fun the past month messing around with namespaces in 5.3, and I have got to say, they are the greatest addition to PHP yet. If you are unfamiliar with namespaces, it's a feature that allows you to add another layer of ownership and packaging to functions and classes, similar to how classes add a layer onto methods (ala functions).

In most applications and frameworks, you would see classes with very long names (I'm pointing the finger at you Zend!). This was implemented so that the classes would not conflict with internal and external (3rd party vendor) scripts. This is no longer the case, we can simply use namespaces! Lets take a look at some code we would write in 5.2 and lower.

class App_Utilities_Session { 
	public static function get($key) { }
	public static function set($key, $value) { }
}

// Basically, annoying!
App_Utilities_Session::set('User', array());

You can see how this would get really annoying and time consuming having to write the long class names over and over again through out your application. We can now rewrite the code above using namespaces. Do note, that the namespace declaration has to be at the very top of your code; although comments and the declare() function can be above it.

namespace App\Utilities;

class Session { 
	public static function get($key) { }
	public static function set($key, $value) { }
}

// Still kind of annoying
\App\Utilities\Session::set('User', array());

Now you may be thinking how this would make any difference, it's still a long class name to write... actually its even longer! Yeah well, namespaces also come bundled with aliases, if you don't feel like writing such long strings. Aliases allow you to declare alternative names for namespaces within the current scope (file). To apply an alias, you would write the "use" command with the Namespace path. You could either call the namespace by its base class name, or you can give it an alias. For example:

use App\Utilities\Session;

// Now that is much easier!
Session::get('user');

use App\Utilities\Session as S;

// Even easier!
S::get('user');

Even though namespaces are great and add extra functionality, there are a few things you should know about. Firstly, any class or function that isn't namespaced, or is within the global scope (SPL, Exception, etc), must be prepended with a backslash. If the backslash is not present, PHP will believe the class is within the current namespace and it fail.

$d = new \DirectoryIterator();
$e = new \Exception();

You would also need to prepend any global function. However, while developing I found that the backslash is not needed, unless you have a custom method with the same name of a function within the global scope.

class Debugger {
	public static function log() { }
}

// Use the global log function
$o = \log();

Another benefit of using namespaces is when you structure your application and file paths to mirror the namespace names. For example, if I use the Session namespace above, I may have a folder structure like so.

// App\Utilities\Session
/app/utilities/session.php

This comes in handy when you have a custom function to convert a namespace into a file path, and vice versa. Furthermore, the get_class() method will now return the classname with the full namespace declaration.

$class = get_class($session);
// App\Utilities\Session

There are loads of implementations of features related to namespaces, I have only named off a few of the important ones. If you have not used 5.3 yet, I highly recommend you do so. Either by upgrading your server or installing a local server; my localhost of choice is XAMPP (it comes with 5.3 by default!). I also highly suggest looking at the namespace guide for more information.