Nerds who love the symfony-project
24 Oct
Fabien Potencier writes:
PHP has greatly evolved over the years as far as reusability is concerned. Since PHP5, the object implementation is much better, and when traits will be supported in the next version of the language, we will have a solid general purpose language at our disposal.
I didn’t know anything about traits, so I went and looked at the RFC:
Traits is a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way, which reduces complexity and avoids the typical problems associated with multiple inheritance and Mixins. They are recognized for their potential in supporting better composition and reuse, hence their integration in languages such as Perl 6, Squeak, Scala, Self, Slate and Fortress.
I’d noticed that PHP had been drifting in the direction of Java, though I’d never seen it explicitly stated as a goal before:
Code reuse is one of the main goals that object-oriented languages try to achieve with inheritance. Unfortunately, single inheritance often forces the developer to take a decision in favor for either code reuse or conceptual clean class hierarchies. To achieve code reuse, methods have either to be duplicated or to be moved near the root of the class hierarchy, but this hampers understandability and maintainability of code.
To circumvent this problems multiple inheritance and Mixins have been invented. But both of them are complex and hard to understand. PHP5 has been explicitly designed with the clean and successful model of Java in mind: single inheritance, but multiple interfaces. This decision has been taken to avoid the known problems of for example C++.
The core team at Symfony wanted to introduce something like mixins, but they were up against the limits of the PHP language. As a partial workaround, way back in 2006, they introduced the sfMixin class:
New mixin feature. The sfMixin class introduces mixins in PHP, allowing core classes modification without inheritance, addition of new methods to existing classes, and multiple inheritance.
The sfMixin class has since become the main tool that allows for registering hooks in Symfony, the same mechanism which allows database/model behaviors. But sfMixin will always be only a half-way solution, as it is a class, and not part of the language. I think what Potencier is saying is that what PHP really needs is a feature in the language that allows this kind of code re-use, and he looks forward to seeing traits in the language for just this reason.
Traits are defined in even simpler terms than Mixins:
As already mentioned, multiple inheritance and Mixins are complex mechanisms. Traits are an alternative which have been designed to impose no additional semantics on classes. Traits are only entities of the literal code written in your source files. There is no notion about Traits at runtime. They are used to group methods and reuse code and are totally flattened into the classes composed from them. It is almost like a language supported and failsafe copy’n'paste mechanism to build classes.
If I understand this right, the goal of this simplicity is to avoid the explosion of methods that may constitute an anti-pattern of Mixins. As Michele Simionato argued in “Mixins Considered Harmful”:
Injecting methods into a class namespace is a bad idea for a very simple reason: every time you use a mixin, you are actually polluting your class namespace and losing track of the origin of your methods. In this sense, using a mixin in a class is just as bad as using from module import * in a module. However, everybody agrees that it is much better to use the full form mymodule.myname instead of importing all the names in the global namespace, but nobody realizes that importing methods into a class via a mixin is potentially just as bad. …To trace the origin of the methods and to keep in mind the hierarchy is practically impossible.
Those of us who make our living from PHP have a lot to gain from traits. They will give us the flexibility that other languages enjoy via Mixins, but traits have the advantage of not becoming part of the inheritance tree, and therefore they avoid the headaches of Mixins.
I am curious to see how Potencier, and the other core programmers, work this into Symfony. We can get a hint from Potencier’s newest project, the new template engine called Twig. Potencier says Twig will be supported naively in Symfony 2.0.
6 Responses for "Traits for a new template engine"
[...] I’ve a new post up over at Symfony Nerds. It is all about how ‘traits’ will bring something like Mixins to PHP. [...]
[...] About reusability, he says he is looking forward to having ‘traits’ in PHP. See my last post for more about that. [...]
I think traits would be something like module mixins in ruby, if you’re familiar…
davide, ‘traits’ would not become part of the inheritance tree of the class that you include them in. So, for instance, if you have an IDE that shows you all the methods in your class, you would avoid the explosion of methods that Michele Simionato wrote of. Really, if you want to know the worst anti-pattern of Ruby Mixins, read Michele Simionato’s article. I linked to it above.
I am not really fond of mixins. Hooking code is unpredictable. And you can achieve code reuse by other means. Like injecting a service with IoC.
I would never have thought somebody says: inheritance is for code reuse.
if you do want to code crossfunctional code only once, I would go into the direction of AOP. (Not sure if traits mimic that)
Fabian, seems like you could recreate some aspects of AOP using traits. But certain styles of action hooking would still need to be done with factory methods or closures.
Leave a reply