In early March 2012, the PHP Group announced the release of PHP 5.4. Developer eagerly anticipated the release because of the many new features 5.4 would bring, the most sought after being traits. In the build up to the release, Shameer C wrote a fantastic overview of using traits in PHP, and I highly recommend reading Shameer’s article before this one because I assume you have a basic understanding of traits.
Traits have been generally accepted by the PHP development community, mainly because it’s a feature that exists in other programming languages like Java, C++, and Phython. Additionally, the benefits of traits have been widely touted, with developers giving their own two cents on how traits can benefit any project, especially as a replacement for OOP inheritance. But are traits actually that good? Are they a feature which will help raise the level of PHP development, or are they just a fad?
PHP Traits are Bad
On the surface, there is strong support for PHP traits because using them can help reduce code duplication throughout your application. In addition, they can help improve maintainability and the cleanliness of your code.
Traits are certainly welcomed, but many leading developers fear they may be used in ways that were never intended. Anthony Ferrara is one such developer, with his fear going so far as to contemplate the possibility of traits becoming the next most abused feature alongside eval and constants. But before Anthony makes his case, he raises a very interesting point: traits are actually a collection of specific mixins, which essentially don’t have state. PHP’s implementation of traits does allow states to be used, and therefore traits in PHP are actually mixins. This simple fact questions the true intent of PHP traits as ultimately they are flying under a false flag. There is no explanation regarding why traits are actually processed as mixins rather than the globally-acknowledged stateless mixins they should be.
Anthony continues, citing that traits are very close in functionality to what extends allow us to with regard to coupling classes together. With extends being a well-respected and long-used feature, it is only fair to ask whether traits truly have a place in PHP or are they trying to stand atop the shoulders of existing features in an attempt to look tall?
Then there’s also the question of interfaces. Many developers have only a vague idea about what the real difference is between interfaces and traits; their ability to be reused is very similar, and the inheritance depth possible with them is also very similar. Are traits actually something new to PHP, or are they really just an upgrade to interfaces?
PHP Traits are Good
Regardless of the unanswered questions, traits are great for PHP, allowing us to create multiple inheritance scenarios (extends only supports single inheritance).
Single inheritance has been used for many years now and comes part and parcel with object orientated programming in PHP, which has restricted advanced programmers from developing complex systems while keeping code clean and to a minimum. In other languages, multiple inheritance could be used to eliminate duplicate code in such situations. But multiple inheritance isn’t possible in PHP. Interfaces are instead offered as a substitute, and an unsuccessful one at that.
Interfaces are not intended to be used in this way, rather to act as contracts which force any classes that implement it to deliver its functionality. This can help open up the coupling of classes and methods, but doesn’t offer a true substitute multiple inheritance in PHP.
A few developers have attempted to create some creative solutions for multiple inheritance in PHP, but many are bloated, making the overall result redundant and more of an experiment than a practical solution.
With traits, multiple inheritance can be implemented naturally using ingenious systems. As Shameer showed in his introduction to traits, you can create multiple traits inside classes. John Squibb uses the multiple traits to create a multiple inheritance environment in his 2011 example.
Many programmers think multiple inheritance is evil citing the Diamond Problem, and claim single inheritance provides less headaches. The fact of the matter with PHP isn’t the practicality of implementing multiple inheritance but rather the symbolism that comes with the possibility of implementing multiple inheritance. This has become ever more important in light of many of the programming public stating their dislike for PHP, evident if you google “don’t use PHP”. With the possibility of multiple inheritance, PHP becomes a more challenging, more expressive, and more acceptable programming language, rather than just the “most common web language”. I find this incredibly comforting when Java, Python, or C++ programmers try to dismiss PHP because of its lack of support of standardized programming methods across languages.
Traits are a true indication that PHP is slowly and surely become a language which will embrace more and more standard programming techniques, hopefully winning over many more established programmers and developers.
Traits allow PHP developers to create cleaner, simpler, and more efficient code while also allowing more complex systems to be made and experimented with.
They’re not good; they are fantastic! They open up another level of development techniques to OOP programmers using PHP, and I believe they are a sign of things to come in future PHP versions.
For more information on the topics mentioned in this article, including a low down on traits themselves, please see the following links:
- Ircmaxell’s Blog: Are Traits The New Eval?
- John Squibb’s Programming Blog: Multiple Inheritance in PHP 5.4 using Traits
- AzonMedia: Multiple Inheritance in PHP – a Workaround
- Refulz PHP: Traits in PHP 5.4 – Why we need Traits
- Christer’s Blog o’Fun: Playing with Traits in PHP 5.4alpha1
- Slideshare: PHP Traits, Treat or Threat?
- Refulz PHP: Traits in PHP – Multiple and Nested Traits
Image via Fotolia
- 1 How to Add Real-Time Notifications to Laravel with Pusher
- 2 Make Your Own Social Network, Game Server, or Knowledgebase! - Sourcehunt
- 3 Crash Course: Continuous Deployment with Semaphore CI
- 4 Poka Yoke - Saving Projects with Hyper-Defensive Programming