On the PHP::Impact blog today Federico points out a Django templating language clone for PHP - Calypso.

Calypso is a full clone of the Django Template Language that helps developers separates the presentational and logic concerns of the application. It offers template inheritance, pluggable tags and filters, and can be easily integrated into the Zend Framework

The most powerful part of the Calypso system is the template inheritance. It allows you to build up a skeleton of templates that can be used for the entire site with blocks and areas that any other part of the application can easily override.

On PHPBuilder.com today, there's a new tutorial that takes a beginning look at PHP5's class inheritance model.

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.

They choose to go with a "car" illustration instead and show how a child of the Product class (Car) can access the private properties of the parent. They also include an example of it in action with a bit of HTML output.

Nick Halstead has posted a few more of his programming tips in the series he's running - three more to be exact dealing with readable code, aggregation, and code structure tips.

• Programming Tips #3 "Divide, Indent, Comment and Name": "We all started programming at some point in our life, some of us on our own, some under guidance of teachers, parents, but even now there are few tips, that should be known by everyone."
• Programming Tips #4 "Aggregation over Inheritance": "My favourite rule is to favour aggregation over inheritance."
• Programming Tips #5 "Readable Code": "It's easier to debug, and later to maintain. Make it readable by using descriptive identifiers, properly tabbing the code, and breaking down the application into functional and reusable pieces."

You can check out the full list of his programming tips in this list.

Larry Garfield has put together some benchmarks based around a request he had from other developers (the "performance czars") as to how the magic functions in PHP5 would perform in the new environment.

Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

He an his tests on a Thinkpad (Intel Core2 Duo 2.2Ghz) running Kubuntu and PHP 5.2.3. They were run two million times benchmarking the different methods for:

• function calls
• __call
• __get
• __set
• iterators (array)
• inheritance
• composition

His results are listed at the end of the post.

Travis Swicegood has made two blog posts about his agreement with other statements made about why class inheritance sucks.

From the original comments made by Bernard Sumption:

All of the pain caused by inheritance can be traced back to the fact that inheritance forces 'is-a' rather than 'has-a' relationships. If class R2Unit extends Droid, then a R2Unit is-a Droid. If class Jedi contains an instance variable of type Lightsabre, then a Jedi has-a Lightsabre.

Travis agrees and then comes back with his second post to clarify something - composition versus inheritance:

I approach OOP from a flexibility standpoint with one of its biggest flex-points being loose coupling which in turn promotes reusability. I'm going to use Event as a hypothetical example.

He uses Events and design pattern illustrations (like the Visitor and Observer) to help illustrate his point.

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.

Frank Kleine has voiced his disapproval with what he calls the "Inheritance Nazi" exception handling PHP has natively.

The built-in Exception class in PHP is total crap. It is an inheritance nazi preventing you from doing useful stuff in your own exception classes. Whoever made its get*() methods final and the trace property private did not thought any second about how exceptions may be used or that people need to implement their own stack trace handling.

The reason for the rant is due to a project he's currently working at where he cannot overload the stack trace of an exception instance then throw the exception. This forces him to create his own exception handling, pointless when the PHP one should be able to handle what he wants.

Suggestions/thoughts in the comments sympathize with him and suggest an alternate exception method - an interface that would allow for more customization.

For more information on the exception handling PHP has, check out the manual page for it.

DevShed finishes off their two-part look at working with Inheritance in a PHP5 application (their web site template engine) with the second tutorial, a look at making the look consistent across the web engine's outputted pages.

In this final installment of the series I'm going to complete the creation of the sample website by developing a pair of additional web pages, which will come in useful for building the typical "Products" and "Contact" sections of the web site in question.

They start with an overall look at how the class will end up before getting into the parts that will need to be added. They extend the base classes even more with more inheritance, making classes for both the Product and Contact pages to render the needed elements.

David Sklar points out an issue that keeps coming up over and over again in the course of object-oriented applications - why the static keyword doesn't know about inheritance.

There are plenty of good reasons why PHP 5 works this way and it seems that in PHP 6 the static keyword will be able to be used in place of self to get the dynamic behavior a lot of folks are looking for. [...] All well and good once PHP 6 is done.

In the meantime, I was noodling around with runkit and came up with some glue that lets you do something like this.

In his runkit example uses a glue class called MethodHelper that uses various things (including some reflection) to manually look into the classes and find the static information.

A fun proof of concept, but not something (for efficiency reasons) you'd probably want to run on a busy production site.