Our first idea, and it was not that bad, Drupal does just the same, was to have a database table with the common fields, a field containing the type of item (it's either an event or a blog post) and a data field where we serialized the corresponding PHP object. This approach was ok until we had to filter or search LabLog items based on fields that were contained in the serialized data.

To resolve the issue they turned to multiple table inheritance, relating the LabLogItem to both a BlogPost and Event. They also show how it could be modeled with a single table, but opt for the multiple method. Included in the post is the Doctrine-based code showing how to create the parent entity for the LabLogItem and the two child entities for the blog post and event. There's also a brief snippet showing how to use them with the EntityManager.

In this article I will discuss traits, a new feature introduced in PHP 5.4 to overcome [issues where multiple inheritance is needed]. The concept of traits itself is nothing new to programming and is used in other languages like Scala and Perl. They allows us to horizontally reuse code across independent classes in different class hierarchies.

Included in the post is example code showing what the use of a trait looks like and a method for creating a Singleton that can spawn instances of two classes. Also included are examples of:

• using multiple traits at once,
• traits made up of traits,
• the importance of order,
• aliasing to avoid conflicts,
• reflection
• and a few other features that come along with their use.

In this article we're going to explore the idea of inheritance in object-oriented programming, and how inheritance works in PHP. With inheritance, your objects and classes can become much more powerful and flexible, and you can save a lot of time and effort with your coding.

They start with the basics of how inheritance works and then move right into creating child classes from a parent. Their example code makes a basic forum system (just example code, not fully functioning) with administrators, members and forum creation. They use this as a base to show the method overriding and exposure with "final". The finish it off with examples of two things that can promote good application structure - abstract classes an interfaces.

In this second and concluding segment, I'll look at some of Twig's other features, including such goodies as template inheritance, custom filters and caching. If you enjoyed the first part of this article, keep reading to find out more about what goes on under Twig's hood, and how you can add even more power and flexibility to your templates

He looks at template inheritance, parent blocks/child templates, data filtering, the tool's "compilation cache" and working with native plugins.

In fact I think that using inheritance all the time is a very big mistake and makes your code hard to maintain and more hard to integrate (the latter is a mistake for application codes and a fatal mistake for libraries). The main problem with inheritance is that if you use it for coupling two classes, then a very important property of the subclass is used up: it's superclass. It is taken, reserved, and it can not be used for anything else furthermore. If you want to connect your subclass to an other class using inheritance, you can't.

He recommends avoiding the typical uses of typical superclass/subclass inheritance unless what you're doing specifically requires it. Working with interfaces, abstract classes and good composition planning is a much better idea.

As a long-time internals.php mailing list reader I am going to tell you a small secret - the first alpha release for PHP 5.4 should be just around the corner. This release is packed with some welcome new language features, usual bug fixes followed by some performance and memory management improvements. One of the noteworthy language additions are Traits - a brand new horizontal code reuse mechanism.

He explains traits as a better way to do the "kind-of" inheritance that PHP does now with parent and child classes, making it easier to reuse functionality from classes even though they don't share the same parent. With the "use" keyword (not to be confused with the "use" keyword in namespaces) you can include common functionality into class methods and even accommodate for naming conflicts and requirements.

Out of the whole discussion, here is the points I got (aka understood) out of it. Please correct me in the comments if I'm off base in any way.

There's two points he makes in the remainder of the post:

• Methods should only be public when necessary.
• Private methods allow you to preserve the class' core functionality.

There's also a bit of code included to illustrate some of his points.

This is a fantastic way to further encapsulate and abstract your code because it means you can define some base functionality and then later on extend that class to add new functionality and even override existing functionality to make the class specific. But this concept is a double-edged sword in PHP (and all other languages).

The problem lies in methods in classes that could be overriding parents and the sort of results that instance of might return in a multiple inheritance environment. He includes code snippets both illustrating the problem and showing a suggestion for how it could be avoided.

What is object-oriented programming? The acronym OOP has become a bit of a buzzword in the current age of programming, to the point where the waters of its definition have become rather murky. [...] PHP may not be object-oriented, but from a purist perspective, neither is Java. What do I mean by "purist perspective?" Plain and simple: everything is either an object or a message being passed between objects (where message parameters are also objects).

He mentions one of the first languages to support objects (Simula) and the four fundamental concepts that would make a language truly OOP - abstraction, inheritance, encapsulation, polymorphism. Its his opinion, though, that while its good for languages to adhere to these four principles as much as they can, discussions about how well they adhere to them is usually just "spinning your wheels" and don't have much use.

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.