On his Tower of Power blog Daniel Cousineau has written up a look at using a more detailed categorization method than just a parent/child relationship on your data - Tree Traversals.

If the software calls for only 2 levels of categorization (Parent and Child only), a simple nested for loop will suffice. However, software requirements change and you'll soon find yourself up shit creek without a paddle if you need to support 3 or 4 levels of nesting. [...] To those who's training is less formal (most web developers I meet have practical training, not formal), I'll help you out: Tree Traversals (or if you are completely lost, Recursion).

He creates a recursive function that, when passed in a category set with different types in it, can handle each of them and then calls itself again with the new child data. His sample code creates url out of a set of categories.

On his blog, Mike Lively has posted a look at some of the work he's been doing on patches for the late static binding functionality to be included in PHP, including an example of the updates in action.

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.

His example shows how to override a static method and push that new method's execution to the parent class (in two ways - safe using forward_static_call and the not so safe calling itself with a parent:: override).

In this blog entry Arnold Daniels talks about an issue he had in the past (needing a bit more functionality than the PEAR DB library could offer) and how he ended up solving it with what he calls a "dark corner" of PHP - class casting.

PHP has a function serialize, which can create a hash from any type of variable, scalars, array, but objects as well. Using the unserialize function, PHP can recreate the variable from the serialized hashed. If we look at how an object is serialized, we see only the properties and the class name are stored.

His method allows for class manipulation via changes to the serialized class information (like changing the value of the name parameter). His "casttoclass()" function makes changing this value simple.

Mike Lively has shared some of his thoughts on the late static binding functionality that will be in the upcoming PHP 5.3 - specifically the relationships of parents and children it has.

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.

He gives an example of what he's talking about (code) and, to help further his cause he's created three patches to make it work how he'd like.

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you're done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

Mike Lively is happy about one thing - that late static binding (definition) has been committed and will be included with PHP 5.3. Unfortunately, he has a downside too:

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.

He talks about the original intention of the functionality (flexible inheritance for static methods/properties/constants) and how it was implemented, but with one small issue - that "static will ALWAYS return the 'resolved' name of the class used to call the current function". He illustrates with a code example showing an extended class returning a static property.

He also mentions two suggestions to help fix this issue:

• setting the behavior of parent:: such that it forwards the calling class through the next function call.
• introducing another scope [...] using a new keyword so parent:: could remain the same

WebReference.com has a new tutorial posted today (from Kris Hadlock) concerning the class inheritance functionlaity that's a part of the object oriented structure in PHP:

There are many benefits of inheritance with PHP, the most common is simplifying and reducing instances of redundant code. Class inheritance may sound complicated, but think of it this way. Consider a tree. A tree is made up of many parts, such as the roots that reside in the ground, the trunk, bark, branches, leaves, etc. Essentially inheritance is a connection between a child and its parent. [...] This article assumes a basic understanding of OOP with PHP.

They show how to create the parent object as a base and how to inherit it into a child class - using the extend keyword in the class definition. They give an example of their sample code in action so you can see how the inheritance is handled.

In a post from Lukas Smith, he gives responses to some of the questions/comments people have to say about PHP, specifically in how it's related to Java.

Whenever someone asks me why PHP is more "agile" than Java, I tell them that in PHP you can break most of the rules your comp sci course told you about and get away with it. Of course this means that you need PHP developers to constantly clean up their code.

He talks about rules for developing in PHP, one being not to change a method so make it incompatible with its parent. He recommends one way to avoid this - the E_STRICT warning to protect against possible conflicts and issues (the same kind of functionality in PHP6 is in E_FATAL though).

Please, lets get the sense back here. Lets not make things that are not fatal an E_FATAL. Lets use E_STRICT for the pedantic, lets add a E_DEPRECATED for all things deprecated. Lets not kill what makes PHP more agile than those other languages that think they know what I should be spending my time on.

On php|architect's A/R/T article repository today, there's the next in a continuing series Scott Mattocks is doing on PHP-GTK 2. This time, he looks at how to manage the layout of your application with the given functionality.

In the last article, "Hello PHP-GTK", we looked at what it takes to create a simple application. At the end, we were left with a PHP-GTK implementation of "Hello World". The application was very simple. Too simple. All it did was display one line of text in a window. In this article we will expand on the previous article by adding more content to the window. Along the way we will look at how parents and children interact and what it takes to make children behave properly.

He starts by explaining the parent child relationship between the base window and other children (spawned) windows, mentioning the GtkWindow and GtkObject widgets. With windows down, he moves on to "boxes", seperation areas inside the windows to help organize the content (including ways to frame them in). And, to wrap it all up, a look at GtkTable, a widget that helps you create a nicely laid out table inside of your window (simpler than several boxes).