On the Coder's Lexicon site, there's a recent post talking about the author's love/hate relationship with PHP traits, a relatively new feature of the language that apps for more "drop-in" functionality similar to mixins in other languages.

When I saw the introduction of PHP traits in 5.4.0 I was eager to learn all about them and how they worked. [...] PHP traits, in my opinion, are handy and very flexible. I guess that is the “love” part of my relationship with them. [...] However, I feel that traits also meddle with a bit of the inheritance rules that have been proven time and time again. Is it possible to love as well as hate something at the same time?

He talks first about "the love" he feels for using traits in his code. He talks about their usefulness for geting around PHP's single inheritance structure and being able to "bolt on" functionality as needed. Then comes "the hate" of them, noting that in the wrong hands, they could lead to very messy and lazy coding practices (including the deadly diamond of death problem).

PHPMaster.com is back with the third part of their series looking at the internals of the Yii framework (specifically, its components). In this latest article Steven O'Brien focuses on how the framework uses behaviors.

A behavior, as it is called in Yii, is a manner of combining objects at runtime to extend an object’s functionality. Behaviors are an excellent way to decouple code and keep ever expanding systems maintainable. [...] We can not reuse our code effectively because PHP doesn’t support multiple inheritance. The Yii behavior system is a way of achieving multiple inheritance by implementing mixins.

He gives an example of working with a user that's connecting to your application just to get to a third-party billing system. They show how to take this functionality our of your generic "User" class and make a behavior out of it. This functionality can then be attached to the User object (via an attachBehavior call) and used directly. He gets into how Yii does this magic, showing how it appends it to a special value in the class and the __call method checks the method call to see if it exists in one of these special classes.

In his latest article comparing some of the functionality of PHP to Ruby, Dave Kennedy looks at modules, mixins and ducks and how they compare to PHP's interfaces and abstract classes.

If you have been writing PHP for a few years you will no doubt have come across Interfaces and Abstract classes. They were introduced in PHP5 object model and since have had medium usage in the PHP world. If you Google "PHP Interfaces" you will get some results on the official documentation and the rest saying how pointless they are. Why the divide? I believe it is mainly down to lack of understanding to what interfaces give you. They imply what your classes should do, but that’s it. Yep, we are talking programming contracts.

He starts with some code examples of an interface and a class that implements it (to work with PDFs). He makes an abstract class to extend the functionality even further and allow for different kinds of reporting PDFs to be generated. From there he moves into the Ruby world, showing examples of duck typing and modules to avoid duplication (mixins).

In a response to a response (from Arnold Daniels) on his article on the ActiveRecord pattern in PHP, Flinn Mueller has come back once again with more comments, both in response and to share some more opinion on the matter.

Today I saw a big traffic increase from my PHP and ActiveRecord post. It looks like PHPDeveloper posted a link to the article and response, so I've written a response to the Arnold's wor(l)ds response post. Arnold's post is insightful, references runkit and has a good implementation of a Sortable tasklist example in PHP.

Flinn breaks it out into a few different topics - things like:

• Ruby objects are (native) Ruby objects
• a brief look at "lineage" for both PHP and Ruby
• The usefulness of Ruby mix-ins
• Issues with static inheritance in PHP
• and some of his suggestions on what PHP6 really needs

In a response to a response (from Arnold Daniels) on his article on the ActiveRecord pattern in PHP, Flinn Mueller has come back once again with more comments, both in response and to share some more opinion on the matter.

Today I saw a big traffic increase from my PHP and ActiveRecord post. It looks like PHPDeveloper posted a link to the article and response, so I've written a response to the Arnold's wor(l)ds response post. Arnold's post is insightful, references runkit and has a good implementation of a Sortable tasklist example in PHP.

Flinn breaks it out into a few different topics - things like:

• Ruby objects are (native) Ruby objects
• a brief look at "lineage" for both PHP and Ruby
• The usefulness of Ruby mix-ins
• Issues with static inheritance in PHP
• and some of his suggestions on what PHP6 really needs

In his latest post today, Ivo Jansch talks about a concpt from Ruby that he likes and wanted to try to implment in PHP - mixins.

Mixins are a way of 'mixing in' functionality of other classes. A kind of 'multiple inheritance' like approach, only without actual inheritance. It is similar to interfaces, but interfaces only tell you that an object must implement certain methods, whereas mixins also provide an implementation.

To help clear it up a bit he links to two articles on the topic. He gives some examples, though, of how it all works by creating a mixin class (Alertable) and the wy to apply it (in the Hello class). The key between the two is the Object class he's created. It allows the two other classes to work with each other without the need for cumbersome includes or passing around objects. All methods are magically available to the Hello object.

Of course, it's not a perfect implementation because PHP just can't do some things, but he includes a few of these things to watch out for in using this method.

In his latest post today, Ivo Jansch talks about a concpt from Ruby that he likes and wanted to try to implment in PHP - mixins.

Mixins are a way of 'mixing in' functionality of other classes. A kind of 'multiple inheritance' like approach, only without actual inheritance. It is similar to interfaces, but interfaces only tell you that an object must implement certain methods, whereas mixins also provide an implementation.

To help clear it up a bit he links to two articles on the topic. He gives some examples, though, of how it all works by creating a mixin class (Alertable) and the wy to apply it (in the Hello class). The key between the two is the Object class he's created. It allows the two other classes to work with each other without the need for cumbersome includes or passing around objects. All methods are magically available to the Hello object.

Of course, it's not a perfect implementation because PHP just can't do some things, but he includes a few of these things to watch out for in using this method.