I have now just committed YAML data sets to the Database Extension for PHPUnit. So now all those that love the simplicity and straightforwardness of YAML can use it with your data sets. I have also created a persistor for YAML datasets so you can easily convert existing data sets or database data into YAML representations.

This is really the first I have dealt with YAML and it is definitely a viable alternative for data sets. Here is what they will look like.

The biggest issue I had was figuring out how YAML dealt with trailing line breaks. It appears that '|-' did the trick. It will strip the final line break. Another thing to take note is that indention is important. It doesn't HAVE to be spaces (it can be tabs) it just needs to be consistent. The last thing is that strings do not need to be quoted, but if they are you can use escape characters (like \n.)

This was committed to the trunk of PHPUnit and I anticipate Sebastian will be merging it back into 3.4 shortly.

I have finally gotten some time to do some long awaited work on PHPUnit. The first on my agenda was a small improvement to filtering. This was related to ticket #526. Essentially I added the ability to do both white list and black list filtering.

For instance, if you wanted to specify an include filter you can do the following:

I have also deprecated passing the filter to the constructor. The reason for this is that I would like to begin adding a few more features to the filter and the current method of passing the parameters on the constructor would be unintuitive for these planned features. Basically I think it was a mistake for me to allow the passing of filter data on the constructor to begin with. I anticipate the current method working up to PHPUnit 4.0 but it will not be expanded on and will be removed either in PHPUnit 4 or in a release soon after that.

So, for exclude filters, instead of specifying them in the constructor, the new method will be:

While you can't mix include and exclude filters for tables (wouldn't make sense right now) you CAN do this for table columns of separate tables:

Some future features I plan on adding include, global column includes/excludes and wild cards. Anyhow, hope this is useful for someone.

One of the most derided, yet most loved and used patterns is the singleton pattern. Its supporters continually praise its ability to limit instantiation of objects and its opponents continually chastise its tendency to be little more than a glorified global.

While programming in many ways boils down to a matter of preference (you can always find someone that agrees with you,) I thought I might as well document my opinion so that those who don't care can have one more thing to ignore.

Details after the jump

PHP5 CMS Framework Development (published by packt publishing) is a a book that offers "Expert insight and practical guidance to creating an efficient, flexible, and robust framework for a PHP5 based content management system." Upon reading through the book I have found that it gives an excellent case study of Martin Brampton's approach to CMS design and implementation. Brampton has been very active in the PHP CMS scene for several years working on widely known projects such as Mambo and Joomla. He is also the creator of Aliro, a newer CMS that had the purpose of utilizing more of the object oriented abilities of PHP5. His experience designing and developing Aliro influenced much of this book.

One might be concerned that the ideas in this book are slanted towards how Brampton decided to implement various aspects of Aliro. While it is true that much of the book uses code directly out of Aliro, I feel that he did take the time to make sure he explained the reasons for the design and development decisions he made. This is the feeling that brings me to the overall conclusion that this book is ultimately an in depth case study of the design of Aliro. If you are interested in developing your own CMS framework or have already developed a framework that you would like to extend, then I would highly recommend this book. Even if you do not agree with all of the concepts and ideas presented it does a fantastic job at pointing out potential pitfalls and other items to consider as you work on your CMS.

After the jump I give a chapter by chapter breakdown of the book.

Over the last couple of months there is a concept in object-oriented programming that has been bothering me. This is the notion of 'programming to an interface, not an implementation'. This is a principle I first learned about when reading "Design Patterns: Elements of Reusable Object-Oriented Software" and then further solidified when I read "Head First Design Patterns". So when I say "programming to an interface, not an implementation" what exactly do I mean? Bill Venners interviewed Erich Gamma (interview here), one of the "Gang of Four" that co-authored "Design Patterns", for Artima Developer during which time he asked the same question. The paraphrased answer is that it helps to limit the introduction of dependencies in your code. Limiting dependencies makes your code easier to test, easier to deploy and easier to change.

What is the problem?

You may now asking, "Mike, why does this bother you? It seems like a straightforward concept and I can't imagine that you would disagree with it." Well, you are mostly correct. I don't at all disagree with this principle of reusable object-oriented design. In fact I try to embrace it. The reason it is bothering me is because I don't believe it is really that simple of a concept and it is 'accidentally' ignored by developers quite often.

Story Time

So, lets go back a couple of months. As some of you know (and most of you don't) I am currently a lead developer for a loan management platform for Selling Source, Inc. Part of my job as a lead developer is to oversee the architecture of our software and make sure it is going in the right direction. One of our projects at the moment is to revamp the search functionality of the software. I'll try not to bore you with too many details (if you want more maybe I'll write TWO blog posts this quarter.) We are denormalizing some of the frequently updated (and obnoxiously wide) tables involved in searching in order to allow moving indexes off of the primary tables in order to improve the update and insert speeds on the primary tables while improving the search speed in the new tables. While doing this we also decided it would be a good time to cleanup some of the code related to searching. One of the ideas was instead of building queries with string concatenations as weare currently doing we could utilize a 'query builder' to create the query. This would allow for more extensibility as responsibility for building the query would reside in an object that could be modified and manipulated much more elegantly than a string.

In the interest of not reinventing the wheel I had one of my developers research other, already existing query builders. The results of his search pointed us to the Zend Framework query builder: Zend_DB_Select. Now I did have a few requirements in my head for what I would like to see out of this external query builder. This first one being that I wanted it to be stand alone. I did not want to have to bring in a bunch of extra baggage that I simply did not need. I was not looking for a framework, we already have one of those. I was looking for a component that we could plug into our existing framework.

Therein lied the problem with Zend_DB_Select. If you look at Zend_DB_Select from the view point of "What are its dependencies?" You will quickly find that there is a class wide dependency on Zend_Db_Adapter_Abstract. This is an abstract class that essentially acts as a wrapper for the existing PHP database libraries. It provides a wealth of functionality including a unified interface for database interaction, a hook for a query profiler and some utility functions. I am sure in the grand scheme of the Zend Framework this is a very good and worth while class. However I would to make the argument that there is no reason for Zend_DB_Select to have a dependency on this class and the basis for that argument is an aspect of limiting your dependencies by truly programming to an interface.

How We Can Use It

So there are four ways that I would be able to use Zend_Db_Select as it is implemented right now.

1. Change my code to utilize Zend's db adapter for all of its connection needs. While the Zend adapter may well be better than the one I am using, I already have established use in over 100,000 lines of code of our own database connection classes. I just need to redesign our search code. Replacing all uses would be completely outside of the scope which in the business world is a bad place to be.
2. Create a Zend_DB_Adapter instance whenever you want to use the query builder. This is not a very good option either. We are using InnoDB for our database. InnoDB performance suffers pretty much linearly with the number of open connections. Creating two connections to the same database on most every request is just a bad idea.
3. Create an extension of Zend_DB_Adapter that decorates (wraps) an existing instance of my connection object. Of all three options so far this one is the most appealing. That being said I still do not think it is ideal. The database connection libraries we use at my office is much more encapsulated than the Zend counterpart. There is alot that Zend_DB_Adapter does that is not in our connection class, it is spread out to other classes such that it can be loaded on an as needed basis. This would make it take some time to write an adapter and would still necessitate us bringing Zend_DB_Adapter into our code base for basically a single purpose.
4. Modify Zend_Db_Select to remove the dependency on Zend_Db_Adapter_Abstract. This is actually the path we are currently exploring. The large downside to this is that we won't be able to quickly get the upgrades or bug fixes from Zend Framework. However I am not too concerned. What we need this class to do is significantly more limited than its current feature set so we will be able to shrink it significantly and with less code comes more stability or at the very least fewer things that could break.

We have identified that this dependency on Zend_Db_Adapter_Abstract is going to cause us all sorts of greif. Lets look at WHY Zend_DB_Select is dependent on Zend_Db_Adapter_Abstract. First, Zend_DB_Select is given the Zend_Db_Adapter_Abstract instance in the constructor. It is then set to the protected member variable $_adapter. So, lets see what all in $_adapter is called throughout the class:

• quoteInto(): 3
• quoteIdentifier(): 6
• quoteTableAs(): 1
• quoteColumnAs(): 3
• limit(): 1
• query(): 1
• getFetchMode(): 1

The first thing you will notice is that all but 3 calls are to methods that are responsible for quoting an object. Now, indulge me for a moment and imagine that those were the only calls made. Why should I need a full fledged connection adapter object to perform quoting? I do realize that some quoting operations depend on the connection (character set, rdbms differences, etc.) But this should not mean that I have to use (in some form or another) Zend's database adapters. I don't want to use it. Mine works extremely well for what I want to do and I am already using it throughout my application.

Moving Closer to Integration Utopia

Now, in a dream world Zend_Db_Select would already be in a state that we could easily plug it into our code without having to go with one of the above four options. What if we created an interface that had a public method for each of the Zend_DB_Adapter_Abstract quote methods? It would look something like this:

The Zend_DB_Adapter could easily be made to implement this interface (you would just have to add the interface to the class definition.) Then I could change the type hint in Zend_Db_Select's constructor to use the new interface. So how would this help my cause? Well now I have a new option. This new option would be to create an implementation of this interface that worked with my existing connection objects. This would be significantly easier than alternative 3. The interface would be well defined and significantly smaller than the Zend_Db_Adapter_Abstract class.

From a design standpoint this interface makes more sense too. The only thing we care about is quoting. So why not specify (via the constructor type hint) that this is really the only thing we are concerned with. It would make the true dependencies of our class much more transparent. From an extensibility and flexibility stand point this is very useful.

So, we still have those other pesky three calls to the Zend_Db_Adapter_Abstract class.

• limit(): 1
• query(): 1
• getFetchMode(): 1

Lets explore why these are there.

The reason why limit() is being used is because different database platforms have different ways to specify limits and offsets. For MySQL you can use LIMIT , LIMIT , or LIMIT OFFSET . Oracle from what I understand doesn't implement limits at all. Now one thing that I find uniquely curious is that all of a sudden in Zend they have moved query building back into their adapters in a very explicit way. So what would I do? Well, since we have already established that quoting really should be connection specific and we have no identified that limits are really connection specific (by virtue of being RDBMS specific) then we could make a small change to the interface above. The first would be to add the limit() function. The next would be to change the name. It is no longer a 'Quoter' it is now essentially performing all connection specific alterations for our queries. So lets try out the name Zend_Db_IQueryModifier. Now before you go yelling at me for that name, let me first say that I suck at class naming. You are more than welcome to 'insert your name here'.

This leaves us with a finding home for query and getFetchMode(). I have a problem with these two method calls. They are both used on a method called query() in the Zend_Db_Select. For the kind of object I am looking for, I don't think these should be here. We already have a class that is responsible for executing queries. Instead of calling 'query()' on my query builder object I would much rather pass that object to my adapter. Which is actually what the Zend Framework implementation of this method does. If you do not want to make your adapter dependent on the query object (which I personally would not want to do either) you could have the Zend_Db_Select have a method to return the query. (Zend_Db_Select implements __toString()).

With these changes I (or anyone for the matter) could use the Zend_Db_Select class completely stand alone with no need for any additional, non-exception Zend classes.

I am a Lover, Not a Hater (Oh and I'm Stupid Too)

It is not my purpose to pick on Zend Framework. I am confident that they are not the only example of not clearly thinking through dependencies and I am equally confident that many people find Zend Framework to be very useful for their needs. They just happened to have an easy real world example of ways that code can be made better and I happened to have to spend a significant amount of time inspecting the code for reasons other than writing an article. Just to prove I am not trying to point the finger I have an example that is arguably worse than the one above and it is in code that I wrote. A bug was recently opened for PHPUnit that essentially asked me why I had type hints for the default database connection class of the database extension in several of my files. There was no real need for this. I wasn't as interested in a wrapped version of the class as I was in simply retrieving meta data. In fact to make things even worse I ALREADY HAD an interface for this data. I just simply did not use it in this case. It was a terrible oversight of mine and is an example of even when you know better these kind of dependencies can slip by. If you would like more details I can outline them in another post.

I am Almost Done

So, at the expense of ending this ridiculously long blog posting lets go back to the Erich Gamma interview. In the spirit of programming to interfaces, not implementations, I believe you should limit dependencies to responsibilities not complete classes. If a class truly has only one responsibility, then it is probably okay to use that class name as the type hint. If a class has multiple responsibilities and you have deemed it necessary than I would strongly recommend you create interfaces to indicate the public methods for those responsibilities and use those in your type hints as appropriate.

Now, if you read through the entire interview (and I suggest you do) you will notice that Erich makes some points that might on the surface seem to contradict what I am saying. Erich states "An abstract class is good as well. In fact, an abstract class gives you more flexibility when it comes to evolution. You can add new behavior without breaking clients." This is a very valid point. He does however go on to state, "As always there is a trade-off, an interface gives you freedom with regard to the base class, an abstract class gives you the freedom to add new methods later." So you do have a decision to make. My issue with Zend_Db_Select turned out to be that the dependency in code was deeper than it needed to be. Sometimes you will have a dependency on an abstract class that will be perfectly fine. So long as you keep responsibilities to a minimum via composition among other means (which the second point in that interview helps with.) Then you should find it very easy to program to interfaces.

And here are the advanced PHPUnit slides!

| View | Upload your own

As promised here are my automated unit testing slides for the 2008 DC PHP conference.

| View | Upload your own

I will be flying out this weekend for my first speaking engagement at The 2008 DC PHP Conference. In looking at the speakers list there are a few familiar faces and quite a few new ones so it should be a fun experience all around. I will be giving 2.5 talks this year. One on Beginning PHPUnit Testing, another on Advanced PHPUnit Testing and then I will be giving a joint presentation Andrew Minerd, a co-worker of mine, on distributed CLI processes.

I am fairly excited as this is not only my first time speaking at a PHP conference but it is also the first time I have been to Washington DC. I have a profound respect for the early history of our country and I am looking forward to seeing the some of the landmarks honoring that history. In any case, if you are going to be in DC for the conference be sure to track me down, I shouldn't be too hard to find.

As promised, a couple of days ago the LV PHP User Group had its first meeting. The purpose of the meeting was to see what kind of interest there was and to gather some ideas for future meetings. We had a pretty good turnout for our first meeting. I think around 20 or so people attended and we mingled and talked amongst ourselves for around 2 hours.

We are going to be having another meeting in mid to late may. The current plan is that two of us will be doing a couple of short talks, I will be talking about testing and quality assurance. We also talked about getting involved in the PHP TestFest project. The last thing we decided is that the next meeting will be in a 'quieter' environment. PT's Pub worked well for a meet and greet type of meeting but would be a tad loud for any kind of presenting. It also forcluded some people from attending due to the atmosphere.

When I hear more info about dates I will post it. For those of you that live nowhere near Vegas, maybe you can use us as a way to writeoff a vacation as a business expense?

I am pleased to announce that Las Vegas finally has a PHP User Group and our first meeting is...tomorrow. I am pretty excited as I know there is a fairly decent size PHP programmer community in LV, it just hasn't been organized yet. One of my co-workers Ray Lopez is organizing the group and it looks like we'll have a fairly decent size group at our first meeting. If you are from Las Vegas I would encourage you to attend if at all possible! If you are unable to attend then I would highly recommend you still sign up at meetup.com so you can keep informed of future meetings.

Time: Friday, Apr 11, 2008, 4:00 PM

Place:
PT's PUB
310 E. Warm Springs Rd.
Las Vegas, NV 89119
Directions

I finally freed up some time to finish some quick tests for some of the late static binding patches I made and one of them finally made it into head.

The original post I had bringing up this issue was lovingly title Late Static Binding...Sorta. Basically the original patch alone did not provide a means to override a method, forward execution to the parent method and still preserve the ability for static:: to be anything meaningful. It would be turned into the syntactic equivelant of self::. I came up with a few patches to address this. After several rounds of back and forth about the patches the conversation died out with no decision. I finally resurrected the topic and was able to find concensus for the third patch (forward_static_call()).

This weekend I wrapped up a few small tests and sent the patch in and it was subsequently pushed to php 5.3 and php 6.0. Now, this is not at all the way I wanted things to work, in all honesty I think the patch is pretty hokey but unfortunately nobody really spoke up in support of the changes I wanted to make to parent:: in regards to LSB. So I thought it far more important to make sure there was a way to make sure static methods could be overridden while ensuring that access to parent methods would be unabated.

So now, if you want to override a static method and forward execution to the parent class, the safe way (in regards to static inheritance) is shown in Table2 while the (unfortunately) not so safe way is shown in Table1:

This shows an example of the differences between using parent:: and forward_static_call. I really do wish that the behavior of parent:: would just be modified to work like forward_static_call does. It would be alot less awkward and imo closer to what the average oo programmer would expect. I suppose the issue is up for debate if anyone feels like bringing it up on internals, we aren't stuck with it until php 5.3 rolls . The patch is even available it just needs some more vocal supporters.

In either case at least there is a way around it now...

If you have been following the PHP internals list for the last few weeks you probably have seen a discussion concerning the current behaviour of late static binding (lsb) and how it seems to be unnecessarily limited when it comes to inheritance. I first posted about the limitations of the current lsb implementation as it relates to inheritance in Late Static Binding...Sorta. It has since been revived in this thread on the internals mailing list: RE: [PHP-DEV] late static binding php6.

I won't rehash all of the arguments as you can quite easily find out my full thoughts by previous posts and on that mailing list thread. To put it simply I feel that somehow there needs to be a way to call methods in a parent class without losing the ability to reference back to the original called static.

This (or anything like it) is currently impossible in the current lsb implementation. I spent a bit of my extended weekend preparing three different patches to work around this problem. I just now sent them to the internals mailing list so they can be discussed. You can view this email and get a summary of the patches by viewing my recent php-dev posting.

• lsb.parent-forwarding.patch - Changing the behavior of parent.
• lsb.new-keyword.patch - Adding a new class keyword.
• lsb.forward_static_call.patch - Adding functions to do my dirty work.

All of the above patches are against 5.3. I was having some strange problems with the test suite in php6 so I moved onto php5.3 so I could make sure things weren't breaking on me . If anyone reading this feels as strongly as I do that there should be a way to do this I hope to encourage you to make your thoughts known on PHP-Dev.

Day one of the conference is over and everything has gone well so far. I attended the extending PHP session by Wez, Sara, and Marcus. It was alot of review but it was very informative and brought up alot of things that I tend to forget frequently. It was also good to find out that Marcus has a pretty decent american impression. In either case I have a couple small php extension projects that I am thinking about starting now just to tinker around with some of what they talked about.

I also heard some unconfirmed rumours that database testing was brought a fair amount in the Best Practices tutorial. So if any of you were in that tutorial and have any questions track me down.

After the tutorials were finished all of us from the selling source decided to go into San Francisco for some food and what not. We went to the Stinking Rose which billed itself as a garlic resteraunt and it certaintly did not dissapoint. We hung around for a while to chit-chat and what not. It is my first time in San Francisco and it pretty much has further confirmed that I am definately not a city guy .

Today's sessions are underway and thus far I have found myself working the entire time but I plan on stopping that after the current round of sessions is over. I am looking forward to going to Give Your Site A Boost With memcached from Ben Ramsey and High Performance PHP & MySQL Scaling Techniques by Eli White. We will also be spending some time today setting up the Selling Source booth. We are also sponsering the opening reception tonight in the exhibit hall which I don't really think means anything other than we'll have our logo plastered in a few key places which is always nice. Also we are giving away a fairly nifty prize at the end of the conference to a random winner of a little code challenge that we put together.

If any of the fellow conference goers plan on going to the opening reception be sure to track me down and say hello. I think I am going to leave both my laptop and black berry so there will be no distractions. I would love to talk to y'all about pretty much anything. .

I will be leaving for ZendCon on Sunday. This will be my first zend con and I am really looking forward to going. I was hoping to speak at the conference about refactoring and database testing but alas it wasn't meant to be . I figure it gives me more time to enjoy everyone else's talks and I can also meet the other attendees without the impending doom of everyone in a room paying attention to me.

I will be attending the conference with a sizable group of co-workers from The Selling Source and will be spending some time in our booth in the exhibit hall. If any of you would like to discuss unit testing, late static binding, or what not please come track me down. I am very interested to talk with anyone that may have checked out the PHPUnit Database extension. I have a small list of features that I am hoping to add shortly and would love to hear about any other features people may be looking for.

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.