These problems are related to the inability to share behavioral code through aggregation and the complexity of state transformations. Combining both, your average entity with 5-15 fields can end up with hundrets or thousands lines of code. The solutions to both problems boil down to minimizing duplication and maximizing clarity.

He looks at two different kinds of objects Doctrine uses in its setup, the value objects and method objects, and "maximize clarity" on them by dividing them up into more functional-related objects, passed into each other via method injection.

Both solutions allow to instantiate an anonymous object with properties. They are used as value objects and have no other purpose than storing values, so no logic can be included and they don't come with methods. They can be used as function parameters instead of arrays, for instance. PHP 5.3.0 introduced anonymous functions and closures, so it is now possible to attach functions to these VOs (*). [...] The first thing to notice is that these properties are not methods but callable functions:

In his example, an anonymous function dynamically appended to an object doesn't have access to a property set on the object just one line before. There's a way around it with call_user_func, but it's not practical. His proposed solution is to create a type of Anonymous class that uses the __call method to catch the methods and translate them into calls to call_user_func_array automatically.

Packt Publishing recently sent me a couple of books to review. This post is about the second one I received, Learning PHP Data Objects by Dennis Popel. I was excited to receive this book as PDO underlies a lot of the Zend_Db_Adapter objects that I use in my day to day programming. It seemed like a good idea that I should know more about it.

He provides some good detail of what the book covers (chapter by chapter) as well as a summary including his recommendation for who should use the book and how they can best enjoy its contents.

In Learning PHP Data Objects, the author Dennis Popel examines this new [database access] system and explains how to begin using PDO in development as a replacement for typical database drivers. The book is an excellent introduction to the data abstraction layer and also provides essential insight into the inner workings of database interaction with PHP.

Akash talks briefly about the history of PDO and what it can be used for first, then gets into the contents of the book (things like the intro chapters and the quality of the writing). The thing he thinks makes the bok stand out, though, is the examples and sample code that reflect both simple methods and more complex issues PDO developers might run into.

• phpMyFAQ
• ODFaq
• Lethal Penguin's FAQMasterFlex
• All
• None

Be sure to check out this week's poll that asks which of the four options is the most common perspective regarding objects in PHP.

Sebastian Bergmann works at eZ systems. In his spare time he wrote and maintains the PHPUnit project. (He's worked on other project but since that's what he's talking about at ZendCon, that's what we'll talk about)

The interview is only a few questions long, but it's interesting to see how Sebastian's talk will be heading. There'll be talk of PHPUnit 3 (still in beta), mock objects, and its integration with CruiseControl. Check out the post for more of the questions.

Mastering some of the most popular design patterns with PHP 5 can be sometimes an overwhelming process that requires hard work and experience. However, if you want to tackle the challenge and expand your existing background on them, this article might eventually find a place on your quick reference list.

They start by defining the basic form element class, helping to build out the different elemnts like inputs, selects, and submits. They extend and implement this class with their example, making a complete form with working elements inside.

I was just skimming over Santos' Post about SDO, and was saddened to see more anecdotes and less facts.

Specifically, he mentions two points - one dealing with the definition Jacob gave for the functionality and the other pointing out some better stats that Jscob didn't include in his comments.

Developers will eventually start using it, it will take some time to go from the PHP way to SDO way. It would be easier to jump into SDO once better, more easily interpreted and simple to understand tutorials, code samples, and support is available. IBM tutorials are a little bit technical, with words and complex pictures (UML). Just give me code and explain how it works and let me run with the SDO scissors in my hand.

He talks about the contributions that both Zend and IBM have made to the effort and the lack of features (well, the duplication of current PHP features - XML and database functionality). He has a positive outlook for the overall future of the project, stating that:

I'm quite sure that enough PHP developers are going to embrace SDO in the coming years depending on the coverage it gets that IBM and Zend's investment will pay off in the end.

One of the things that was apparent was that this SDO stuff has quite a high barrier to entry--too many three letter acronyms for starters, and its origins in the C++ and Java world don't help make it very accessible to the typical PHP developer.

Wez references two articles over on the Zend Developer Zone as great places to get started. He also mentions giving some feedback to the IBM folks about the SDO extension:

If you've wondered what this SDO stuff is all about, please read through those articles. After having done that, if theres something you're not clear on, or if everything is clear, or if you have some other thoughts on the matter, then please take a moment to send your feedback to Graham Charters (you'll find his email address on the top of the articles).