Late static binding….sorta :/

The good news is late static binding has been introduced into head and looks like it will be merged into 5.3 before it is released. The horrible news is I really don’t think the patch went as far as it needs to.

If you look at the original posts that cropped up about a year and a half ago the whole purpose of late static binding was to allow the same kind of flexibility provided by inheritance of standard class methods for static methods, properties, and constants. This wouldn’t really open the door for any grandios, new kind of applications, it would just allow a new way to code libraries the most prominant example being an Active Record Library.

This is now possible, however I think there is a very unfortunate limitation that I brought up a few times on the Internals mailing list to apparently no avail. The problem is with the fact that static will ALWAYS return the ‘resolved’ name of the class used to call the current function. So, imagine the following method:

If you call test using Foo::test() then static:: will resolve to the ‘Foo’ class. If you call it using Bar::test() then static:: will resolve to ‘Bar’. This is correct and works well for simple inheritance. However things start taking a downward turn the more you use inheritance. Consider the following change to Bar and the addition of a new class Bar_Child:

Now, calling Foo::test() will again result in static:: being bound to ‘Foo’. However, due to the fact that parent:: will resolve to Foo:: that means the call Bar::test() will now result in static:: being bound to ‘Foo’. Bar_Child::test() will do exactly the same thing, static:: will again be bound to ‘Foo’. This is incredibly inflexible and in my opinion this is the exact problem that ‘late static binding’ is SUPPOSED to fix.

There are a couple of ways to fix this that I can think of right now, unfortunately nobody on list seems very motivated to explore any compromises. The two ways that come to mind immediately are either setting the behavior of parent:: such that it forwards the calling class through the next function call. So in the example above, calling Bar::test() will still result in calling Foo::test() however it will not ‘reset’ the calling class so that static:: will still resolve to ‘Bar::’, likewise Bar_Child::test() will result in static:: being bound to ‘Bar_Child’.

The second alternative is introducing another scope. I have no clue what this scope would be called, but it would basically implement the functionality I just described for parent:: above but would do it using a new keyword so parent:: could remain the same.

Dmitry Stogov mentioned my first alternative on the list however he also included this functionality for the self:: scope which I could see causing some serious problems. In either case, I am thankful that the functionality has started to make its way in, but I can’t help but think that myself and some other early proponents of the functionality are getting completely shafted.

Adding Database Tests to Existing PHPUnit Test Cases

When I was first creating the Database Extension for PHPUnit I realized that there was a very high likelihood that several people would have tests that were already written that they would like to add additional database tests too. To accomplish this I actually wrote the PHPUnit_Extensions_Database_DefaultTester class. In fact, if you were to look at the source of the database test case you will see that all of it’s operations are actually forwarded to this class which does all of the work.

Please continue reading to see how you can use composition to add database tests to your existing test cases.

Continue reading Adding Database Tests to Existing PHPUnit Test Cases

PHPUnit Database Extension (DBUnit Port)

I have completed the initial feature set for the Database extension to PHPUnit. This is a essentially a port of DBUnit to PHP.

For those that may not have read any of my previous postings on the subject the goal of this software is to extend the functionality of PHPUnit to allow using seed data to put a given database into a known state prior to executing each test. It also provides an easy mechanism to compare database contents with an expected dataset.

The database extension has recently been merged into the PHPUnit 3.2 branch and is scheduled to be released in that version. Sebastian Bergmann will be introducing the extension in his Advanced Testing with PHPUnit talk at PHP|Works 2007 in Atlanta September 13 – 14. If you would like to tinker around with the database extension prior to it’s release you can always download the latest copy of PHPUnit 3.2 from svn: svn:// The source can also be browsed at

Please continue reading for an example of how you can now use PHPUnit to even more effectively test data-centric applications.

Continue reading PHPUnit Database Extension (DBUnit Port)