What I didn’t know, is that this could get us into a lot of trouble without even expecting it. The problem occurs whenever you try to obtain a reference to an element in a PHP array. Case in point:

$a=Array("one"=>1, "two"=>2,"three"=>null);
$b = $a["four"];
$c =& $a["five"];

What do we get if we print the value of $a variables? $a is now

$a = Array(
  ["a"] => 1,
  ["b"] => 2,
  ["d"] => null,
  ["c"] => &null
)

WHAT?! What happened to $b? What in the world is a pointer to null? PHP actually created the “c” key within my Array, just by referencing it in a read context. Lesson learned: always use isset($a["key"]) before attempting to draw from an Array by reference!

It’s not much different than Design By Contract, (DBC) – a coding technique promoted in The Pragmatic Programmer, another book I’m reading for work. The thought is that every method has a contract to which it and other methods – and in OOP, objects/classes – abide by. Everyone fulfills their contract, everyone benefits, and the programmer can go home early that night.

The downside, as T.P.P. describes, is that OOP does not lend itself nicely to automatic DBC programming: namely that method inheritance doesn’t imply contract inheritance. This seems like a relatively small gripe to be made about OOP, in my opinion, especially when a simple coding standard can surmount this problem.

In what I’ve learned from OOP, good style is to use both public and private methods, and methodologies, to their advantage. This, thankfully, lends itself well to implementing DBC.

As with most of my posts, this one includes an example!

/**
 * Basic object class, all other classes should extend this
 */
class BaseObject {
    /**
     * Public accessor to the toString() concept
     */
    public function toString() {
        // contract invariants
        $invariants = Array('this'=>$this);
        // contract presumptions
        assert(is_object($this), get_type($this)." is not an Object");

        // inherited method
        $r_val = $this->_toString();

        // contract post assertions
        assert(equals($invariants['this'], $this), get_class($this)."::toString() modified the Object in a read-only context");
        assert(is_string($r_val), get_class($this)."::toString() did not return a String.");

        return $r_val;
    }

    /**
     * Private implementation of the toString() concept
     */
    private function _toSring() {
        $r_val = Array();
        $r_val[] = $this->some_val;

        return implode("\n", $r_val);
    }
}

/**
 * A class which does what it's supposed to do
 */
class GoodObject extends BaseObject {
    /**
     * This function abides by the BaseObject::toString() contract
     */
    public function _toString() {
        $r_val = Array();
        $r_val[] = $this->some_val;
        $r_val[] = $this->other_val;

        return implode("\n", $r_val);
    }
}

/**
 * A mischevious class
 */
class BadObject extends BaseObject {
    /**
     * This function does not abide by the BaseObject::toString() contract
     */
    public function _toString() {
        $r_val = Array();
        $r_val[] = $this->yet_another_val;
        $r_val[] = $this->some_val;

        return $r_val;
    }
}

So we can see that it’s not too hard to notice that the assertions set in place in the BaseObject class will catch whatever the contract for toString() has been set up. Better even than that, the contract can be amended in one place and it will filter down throughout all subclasses. It’s OOP-DBC; and it could save your life – or at least your program.

The problem with making anything a solitary factor more expandable is that it increases the complexity required to interface with that feature by at least twice that factor — twice in the sense that time and complexity, remember them?, are lower-bounded to being capable of handling the expansion.

Case in point: The difference between a pre-populated list and one whose values are variant depending on which portions of a codebase are considered “active.” This can pose quite the problem depending on how mission-critical this list is. (After all, this is a science; and all science should be repeatable ad infinity.) But how to retain this ability to accept a near-infinite range of values and manage them in some human-readable way?

Here we find the strengths and weaknesses of a language. In C, everything you touch is memory whether you realize it or not. From byte-pointers to malloc-ed blocks of hard disk, C keeps you up to your elbows in references. Perl scales the complexity back by a good factor, but grabbing references is still do-able: $ref = \$scalar is a direct accessor to the memory allocated by $scalar; and conversely, $val = $$ref gets the value of whatever variable resides at the memory location $ref. Pretty handy if you have an unknown-length set of variables with similar names. Now we have a common variable name we can manipulate without having a half-dozen Eval() functions in our code. (Aside: Eval() is nice, but sneakily evil; it’s slow, offers arbitrary code execution if use improperly, and just plain ugly.) Our syntax highlighters can show us exactly what we meant, and in six months when we’ll use this as the basis for the program’s next feature, we’ll have a much clearer idea of what the hell we wanted to get out of it.

But this is Perl. How do we do this in a language which masks references like PHP? Unfortunately, we can’t go flying around the memory stack as easily as Perl does, but we can get pretty close with a single Eval(). (Aside 2: I know, I just got done bashing Eval(); I haven’t forgotten, but we’re in control of the string this code evaluates, so take a breath.)

PHP offers an arguably more elegant Eval() than most languages, the inline eval. So let’s reassume our situation: an unknown number of similarly-named variables is in our module’s scope and we want an elegant, memorable way to access their values for modulation.
In Perl:

$value_1 = "some important value";
for($i=1; $i < $some_known_upper_bound; $i++) {
    $value_variable_name = "value_" . $i;
    $value = $$value_variable_name;
    # some modulator code
}

In PHP:

$value_1 = "some important value";
for($i = 1; $i < $some_known_upper_bound; $i++) {
    $value_variable_name = "value_" . $i;
    # the magic...
    $value = ${$value_variable_name};
    # some modulator code
}

And there you have it. Future proof code that modifies a like-named set of variables with a single, easily understood and aptly named variable.