Yes, this is a basic implementation of LOLCODE (an interpreted language) written in PHP (an interpreted language).

At the moment there’s enough implemented to parse and run the following…

HAI. BTW THIS IS A COMMENT. VISIBLE “OH HAI, WORLD”. KTHXBAI.

You can find the source code up on github at github if you want to have a play (just extend \Lol\Token – see visible.php for an example).

The key thing for me is that my code should not care that the data is coming from a relational database. This poses one or two issues.

• In a relational database, data typically has other ‘meta’ data associated with it. Id’s, timestamps and other snippets of information that are not strictly part of what my object is trying to represent.
• If my object is not aware of how it should serialise itself, who is?

This of course isn’t a new problem. My language of choice (currently PHP5) has many ORM libraries available to it – Doctrine, Propel and more – most (or all) of which are loosely based around the Active Record design pattern.

My only problem with these frameworks is that they seem to do too much ‘magic’ for me (and I like to retain at least some control over what’s happening between my app and the database). Of course, it could also be that I have either not invested enough time in learning to use one of them to it’s maximum potential.

Despite that, the Active Record pattern appears to be quite a satisfactory way of creating that link between my application, and how it’s storing it’s data. My core objects can exist how I want them to, and their ‘datastore’ can be represented by an active record object (who’s attributes are exactly the same as the columns in the database) on the class itself. It gives me the degree of separation that i’ve been looking for.

However there’s still a piece missing. My core class still has to contain the relevant logic to load it’s associated active record. This suggests some static factory methods (I refer to my earlier comment on things that smell bad!), so i’m going to create a ‘Builder’ for my core object that’s concerned with marrying up the active record with the core object itself. Here’s how it looks (simplified) in a class diagram.

ActiveRecord class diagram

I’ve not closed the doors on Doctrine or Propel though, so it’ll be interesting so see just what an established ORM framework like Doctrine can do for me on top of this basic implementation.

To an extent this is true – until you are presented with what you do with protected or private methods within classes.

There are two camps of thought on this issue.

One (that I completely and utterly disagree with) says that these methods ARE units in their own right, and should be tested as such (using introspection, or language hacks etc). In PHP this can be accomplished by abusing the __call method in your class (to allow a test suite to call protected or private methods on your class).

The second, is that a ‘unit’ is actually a single call to the public interface of your class. The protected and private methods that are called within the class are implementation details and should be allowed to be refactored entirely. Providing the behaviour and the public interface of the class does not change, refactoring does not involve ANY modification to the class itself.

Because the implementation details of a class do not constitute a unit in it’s own right, testing these methods in isolation are therefore incomplete and actually invalid (as they never have the context in which they are used, and even though your code may show 100% lines of code coverage, the branch coverage will always be far from complete).

So – if you’re tempted to create a test for a protected/private method within a class, then you’re moving away from unit tests and into protecting your implementation using a unit testing framework.

Immediately we blamed the database – it must be the bottleneck – located on a different server and transferring a result in excess of 10,000 records. But when performing the query from a DB client there was virtually nothing in terms of a delay.

So what was the problem? The code was reasonably simple. An in house database abstraction layer was used to construct a representation of each row returned from the database and stored it in a big array. Common OO style promoted the use of a series of ‘setter’ methods to store the data in each constructed object.

class MyClass
{
        private $animal = null;
        private $mineral = null;
        private $vegetable = null;
 
        public function __construct()
        {
        }
 
        public function setAnimal($animal)
        {
                $this->animal = $animal;
        }
 
        public function setMineral($mineral)
        {
                $this->mineral = $mineral;
        }
 
        public function setVegetable($vegetable)
        {
                $this->vegetable = $vegetable;
        }
}

This block of code simulated how each of the objects were being built – using the data as returned from the database.

for($i=0; $i<10000; $i++) {
        $test = new MyClass();
        $test->setAnimal('lion');
        $test->setMineral('stone');
        $test->setVegetable('potato');
}

Surprisingly (or perhaps not…) this code takes around 4.5 seconds to run (obviously depends on hardware!). Quite an overhead when you’re targeting a 2 seconds per page load time!

Looking at the code – the constructor is clearly redundant. It’s not serving any useful purpose. Removing it cut off around half a second of page load time (average).

Removing one of the setters saved another second or so… removing all the setters (just constructing a blank object 10,000 times cut’s it down to 1/10th of a second! Could method calls in php be that expensive?

We can create the same result by doing all of this in a constructor – consider the following.

class MyClass
{
        private $animal = null;
        private $mineral = null;
        private $vegetable = null;
 
        public function __construct($animal, $mineral, $vegetable)
        {
                $this->animal = $animal;
                $this->mineral = $mineral;
                $this->vegetable = $vegetable;
        }
}
 
for($i=0; $i<10000; $i++) {
        $test = new MyClass('lion', 'stone', 'potato');
}

This cut’s things down to just under two seconds – definitely better – but not where we want to be. We know that the presence of the constructor (presumably it’s just the overhead of the method call itself) is costing us some time. What if the class was simply a data container and offered nothing in the way of accessors?

class MyClass
{
        public $animal = null;
        public $mineral = null;
        public $vegetable = null;
}
 
for($i=0; $i<10000; $i++) {
        $test = new MyClass();
        $test->animal = 'lion';
        $test->mineral = 'stone';
        $test->vegetable = 'potato';
}

3/10ths of a second. Ok – now we are getting somewhere! For 10k results – this is probably acceptable.

It appears that object creation and method calling is actually quite an expensive operation within PHP – if we actually had to deal with 100k rows, the fastest way of doing it is always to just use an array. The 10k test completes in less than 1/10th of a second.

A more accurate analysis of just how much object instantiation and method calls cost could be done using xdebug to profile how long each line of code actually takes to execute. But for my purposes, this worked out well.