ArrayAccess allows you to treat an object that implements it as if it is an array for the purposes of setting, unsetting and retrieving data from it. Please note the emphasis in the last sentence! ArrayAccess does not make an object behave like an array in any other way. If you pass an object that implements ArrayAccess to a PHP array function such as in_array() you'll still get an error. This will become a little clearer with some of the examples below.

He shows what you'll need to use this interface in your class - implementing the interface and defining a set of four methods to get/set and check for the value in your array. He includes a practical example of pulling data back from an API and wrapping it in a class to make accessing it simpler (also implementing the Countable interface as well, see the previous post for more on that). Code is include to illustrate how it can be used.

PHP provides a number of predefined interfaces and classes that can really make your life as a developer easier but which are often overlooked. The functionality offered by the Standard PHP Library (SPL) and the predefined interfaces is extremely cool and very powerful but very underutilized. [...] I thought I'd write a few articles with examples of how I've used these classes and interfaces in the hope that someone would find it useful. I'd love it if people felt like commenting with their own examples too. I'll start with a quick look at the Countable interface.

He includes sample code for classes using the Countable interface and defining the custom "count()" method inside. This method lets you define how the object will behave when something like count is called on it. His examples show returning the number of items in a private variable, determining the state of an object and including logic to only find valid data (like from a database table).

Sporting more than 70 native array-related functions, PHP's array manipulation capabilities have long been one of the language's most attractive features. [...] There are however many array-related tasks which ask a bit more of the developer than merely knowing what part of the manual one needs to consult. Many such tasks require a somewhat more in-depth understanding of the native features, or are possible only when a bit of imagination is applied to the problem.

In his examples he shows how to do things like sorting a multi-dimensional array, iterating recursively (with the help of a RecursiveArrayIterator), converting an object to an array and doing "natural" sorting on an array's contents.

Together with its more famous brother "Iterator", they are currently the two only implementations of the "Traversable" interface, which is needed for objects so they can be used within a standard foreach() loop. But why and when should we use the iteratorAggregate?

He answers his question with an example - a book that contains chapters. With a normal iterator you'd have to define standard functions (like valid, rewind or key). Using the IteratorAggregate you can push items into an internal array (like chapters in a book) and call a "getIterator" method to get this set. He also takes it one step further and shows implementing the "Count" interface to make it easier to get a total count of the items in the iterator. Sample code is included to help clarify.

The Filter Iterator is probably my second favorite iterator, next to Directory Iterator. There are many great use cases for the Filter Iterator, and when you do filter the original data is left untouched. A Filter Iterator is really simple to use, create a class that extends FilterIterator and adjust the accept method to meet your criteria. This is great and all, but having the ability to create filter iterators on the fly, ones that won't be used application wide, without having to create a class is even better.

He includes a bit of code defining a FilterCallbackIterator class with a "callback" parameter passed into the constructor (in his case, a closure). Also included is some sample code of it in use - handling an array (well, ArrayIterator) with a simple true/false check on the current array value. You can find out more about this functionality in the PHP manual.

The SplFixedArray class provides a super-fast, fixed size array implementation. There are some limitations however, first you must use numeric keys and secondly you cannot use anonymous assignment (i.e. $array[] = 'value';). You'll notice one requirement was missing, that it should have a fixed size. While having a fixed size is what will bring you the speed increase it's actually not a requirement that the size be fixed.

Because of these restrictions, the SplFixedArray is faster than its cousin - between 20 and 40 percent faster, depending on the size of the array. He includes a few snippets in the the post - one showing how he benchmarked the differences against simple arrays and another showing a more advanced example with another SPL type, a FilterIterator.

To start illustrating why segregated interfaces are really useful, in the lines to come I'm going to build an example that will recreate the scenario described in the introduction. Basically, what I want to achieve here is to construct a custom countable array collection.

He shows the basic class structure needed to emulate a countable array in an object by implementing the "Countable" interface. He adds in the "Iterator" interface to allow you to work with the dataset like an array - progressing through it, rewinding to the beginning and checking to see if a value exists. Finally, they add the "ArrayAccess" interface to the class that boosts it with even more features like the ability to grab things by specific keys (numeric or string). The finish the article off with an example of an ArrayCollection object and how it can be looped through using a foreach.

Working on a symfony app, you usually have a mix of domain objects that are used by symfony actions, interspersed with symfony specific code such as logging and sfContext type stuff. A common bad practice I see is symfony specific code peppered inside of domain objects that could be used elsewhere (such as inside of a Zend app or a script from the cli) but now can't as they're coupled to the symfony code. One way you can remove an unwanted dependency is to use the Observer pattern - the dependency is pushed from inside the subject object to the client code that initialises the subject.

He sets up a scenario where a symfony action hits a web service and there's a dependency on two other types of objects (a service and transport object). He starts with the code for this method and gradually refactors out those two dependencies, removing an sfContext call from inside the service client and adds attach/detach/notify methods to implement the SplObserver on the class.

Since PHP 5, there has been a bundle of built-in exceptions - the "SPL exceptions" - in PHP. However, the documentation for these classes is quite lacking in examples, and it can be difficult to understand when you should be using them. The short answer is always.

The list of exception types he recommends include:

• BadMethodCallException
• DomainException
• LengthException
• OutOfRangeException
• UnexpectedValueException

For each he gives an example usage of it, sometimes including a bit of code to illustrate.

In my previous post, Simple Object Iterators in PHP, we discovered how to iterate over array items defined within an object using a foreach loop. However, what if you need to iterate over items which are not stored in an array, e.g. records from a database or lines of text read from a file?

He shows how to create a script that pulls in the users from a database object (PDO, in this case) and implements the Countable and Iterator interfaces. These interfaces give it some special methods that can give counts of the results and help you iterate through the results - current, rewind, next and valid.