That said…

Most code editors have figured out this whole code folding thing where you click on the minus button next to the function block and it collapses into a neat declaration.

Zend Studio has this too, only with a slight twist. Most of the times it works right. Other times, it forgets to fold bits. Yet other times, especially when folding PHPDoc blocks, the fold swallows whole unrelated fields/functions that happen to be next to the one I want to fold, declaration and everything. Nice.

I could understand this slipping past testing given how intermittent it is, but ZS’s been around for at least a couple of years, and it’s got like a dozen version updates, one of which explicitly touted having better folding. Yeah, it’s better, because before it screwed up half the time rather than a 10th of the time. It still sucks.

And while on the subject of sucking, in what universe is it sensible that if I edit a file that exists in a ZS project outside of the environment, and then try to open it in ZS, it flips out in glorious fashion:

And then I right click on the offending file, click on Refresh, and it’s happy again. If it knows it’s out of sync, why the hell can’t it refresh it automatically? The file’s right there!

Makes me want to hit it. Surely I can’t be the only one running into this stuff?

function do_maintenance()
{
  $db->doSomeQueries();
}
 
function debug_write()
{
  echo 'some debugging information';
}
 
// Last things to execute
register_shutdown_function( 'do_maintenance' );
register_shutdown_function( 'debug_write' );

There’s one caveat, and it’s explained in the PHP documentation:

Multiple calls to register_shutdown_function() can be made, and each will be called in the same order as they were registered.

This means that if I also want to see debug output from the queries in the do_maintenance function, I have to make sure that debug_write is always the last registered function.

This can be inconvenient. Luckily, PHP has a function that allows a script to run code after it’s finished all of it’s processing… And it lets me register another shutdown function inside that function.

register_shutdown_function(
  create_function( '', 'register_shutdown_function(\'debug_write\');' ) // Really last thing to execute
); 
 
register_shutdown_function( 'do_maintenance' ); // Last thing to execute

This assures that the function that it registered will always be the last one, and this way, despite having the debug function registered before the maintenance function, the debug function will still execute last.

A lot of the confusion comes from the lack of documentation. An ArrayObject, the documentation says, is “an array wrapper”, that “allows to recursively iterate over Arrays and public Object properties”. This isn’t very useful, and it doesn’t explain at all what is the ArrayObject actually good for. Iteration over arrays and objects has been long supported simply with the foreach construct:

$arr = array( 'a', 'b', 'c' );
$arr[0] = 'A';
$arr[] = 'd';
 
echo count( $arr );
 
foreach( $arr as $letter )
  echo $letter;

And this is how you’d do it with an ArrayObject:

$arrObject = new ArrayObject( array( 'a', 'b', 'c' ) );
$arrObject[0] = 'A';
$arrObject[] = 'd';
 
echo count( $arrObject );
 
foreach( $arrObject as $letter )
  echo $letter;

Both snippets have the same output. You can use the ArrayObject just like you would use the array because it implements several interfaces from the SPL:

• The IteratorAggregate interface, which lets foreach iterate over its contents by returning an Iterator
• The Countable interface, that tells the count() function what to return when used on the object
• And the ArrayAccess interface, that gives an object the ability to be accessed using the array syntax.

These interfaces are very useful when implemented in your objects, but for the purpose of a simple “array wrapper”, it just adds the overhead of having an object, and then an iterator object to iterate over it. Yet, its exactly what Zend is encouraging:

The ArrayObject class is a powerful tool for iterating through and accessing arrays. Its practical uses are infinite; use it as a wrapper for all arrays: simple arrays, arrays of database records, arrays of objects, etc. Consider the listing in Example 9. Continuing the PartyMember examples from the earlier listings, I fetch data from a database, creating an array of PartyMember objects, from which I then create an ArrayObject object. While this example shows simple iteration with a foreach loop (which I could do when it was a normal array), using ArrayObject provides access to tools that are not accessible to non-object arrays without the use of procedural code and functions. For example, with the ArrayObject, it is possible to sort the array, modify elements or append new ones, and iterate through the results.

This is nice and all, but the only concrete reason they give for using an ArrayObject is, apparently, to perpetuate the object oriented master-race, while oppressing those horrible, evil and icky functions. And this is good enough reason if you’re an OOP purist, and there’s nothing wrong with dreaming of a nice, object oriented, well structured PHP. For me, it just doesn’t cut it. There are reasons why the ArrayObject is inferior in this purpose.

While the overhead is probably insignificant, there’s the thing that an ArrayObject isn’t actually an array, it just behaves like one on occasion. This means that it’s not compatible with most places where you’d normally use an array. You can’t, for example, use most of PHP’s array functions on it directly. Some of the functions, like sorting, are available in the class, but most of them aren’t. For those, you have to extract the internal array, do your operations on it, and then exchange it back in. For me, this seems too much to bother:

$arrObject = new ArrayObject( array( 1, 2, 3 ) );
$array = $arrObject->getArrayCopy();
$array = array_reverse( $array );
$arrObject->exchangeArray( $array );

So what good is the ArrayObject?

Like I said before, it’s got to do with class encapsulation.

We’ve all heard how it’s Evil to directly expose properties of a class. You may or may not accept this as an evangelical truth, but if you do, you might have come across a situation where you need to allow outsiders to interact with an array in your class.

class MyClass
{
  private $list = array();
  public getList() { return $this->list; }
}

The first problem arises in the fact that arrays are passed by value in PHP, meaning, a copy of the array will be passed out from the function, and that means that changing the result of the getList() method won’t actually change the values in your class. To be able to write to the array, you can either provide a setter, implement methods in your class to do adding and removing from the array or pass it out by reference.

class MyClassWithSetter
{
  private $list = array();
  public getList() { return $this->list; }
  public setList( array $list ) { $this->list = $list; }
}
 
class MyClassWithAccessors
{
  private $list = array();
  public getList() { return $this->list; }
  public addToList( $item ) { $this->list[] = $item; }
}
 
class MyClassByReference
{
  private $list = array();
  public &getList() { return $this->list; } // Note the &
}

Neither of these options are very attractive. The first one requires extra code on the outside to get the array, and then set it back in. The second one forces you to implement array access code for every array you want to expose, and the third one is basically exposing the internal array to any kind of modification. There’s nothing stopping someone from doing something like this:

$mc = new MyClassByReference();
$list = $mc->getList();
unset( $list );

Since $list is a reference, unsetting it will also unset $mc’s $list, and unless you check for that everywhere you use it, it can be catastrophic.

And then, there’s the problem of actually using the class. Regardless of whether you pass as a value or as a reference, you still can’t access it without putting it into a variable on its own. This, for example, is invalid syntax:

$mc = new MyClassByReference();
$mc->getList()[] = 'Item 1'; // Invalid
if ( $mc->getList()[0] == 'Item 1' ) // Invalid
{
  unset( $mc->getList()[0] ); // Invalid
}

The right way to do this would be:

$mc = new MyClassByReference();
 
$list = $mc->getList();
$list[] = 'Item 1';
if ( $list[0] == 'Item 1' )
{
  unset( $list[0] );
}

Tolerable, but not optimal.

ArrayObject to the rescue

The solution comes, dragged right out of other OOP languages, in the form of the ArrayObject. Objects, in PHP5, by default, are passed around between functions by making a copy of the reference. That means that if you pass out an object variable out of a function, while it’s a copy of the original variable, it still points to the same instance of the object. This means we no longer have to pass by reference when we expose our list!

class MyClassWithArrayObject
{
  private $list;
 
  public __construct()
  {
    $this->list = new ArrayObject();
  }
 
  public getList() { return $this->list; }
}
 
$mc = new MyClassWithArrayObject();
$mc->getList()->append( 'Item 1' );
if ( $mc->getList()->getOffset(0) == 'Item 1' )
{
  $mc->getList()->unsetOffset(0);
}

And because the ArrayObject has the OOP interface, you no longer have to extract it into a local variable first!

We could stop here, but we still have the issue of someone passing in invalid data into the list. For this, we can simply extend our ArrayObject.

class StringArrayObject extends ArrayObject
{
  public function append( $value )
  {
    if ( !is_string( $value ) )
      throw new InvalidArgumentException( 'Value must be a string' );
        parent::append( $value );
  }
 
  public function offsetSet( $index, $newval )
  {
    if ( !is_string( $newval ) )
      throw new InvalidArgumentException( 'Newval must be a string' );
 
    parent::offsetSet( $index, $newval );
  }
 
  public function exchangeArray( $array )
  {
    foreach( $array as $value )
    {
      if ( !is_string( $value ) )
        throw new InvalidArgumentException( 'Value must be a string' );
    }
 
    parent::exchangeArray( $array );
  }
}
 
class MyClass
{
  private $list;
 
  public function __construct()
  {
    $this->list = new StringArrayObject();
  }
 
  public function getList() { return $this->list; }
}
 
$mc = new MyClass();
 
// these will work.
$mc->getList()->append( 'item' );
$mc->getList()->exchangeArray( array( 'item', 'item' ) );
 
// these won't.
$mc->getList()->append( 123 );
$mc->getList()->exchangeArray( array( 123, 'item' ) );

This is much better. Obviously, you can include any kind of validation logic you want.

It’s not a perfect world. For one thing, I would still prefer to use “[]” rather than “append()“, and “[0]” instead of “offsetGet(0)“. For this, I could use PHP’s “overloading”* to make actual accessors, but I personally think it’s ugly and stupid having to implement plumbing logic for my class that should be in the language itself. Maybe one day PHP will have proper accessors, or support the “getList()[]” syntax.

Furthermore, there’s the issue that the ArrayObject doesn’t support most of the array manipulation functions of PHP, so it certainly can’t be used as an object-oriented array replacement (that would be pretty sweet, really), but given that in its state, the ArrayObject is really only useful for exposing lists from classes that won’t likely be manipulated extensively, its behavior suffices for the purpose. It’s still a good step for a more object oriented PHP.