In PHP 5, I can to overload constructors (and any others methods). But if I get some code like this:
class Base {
public function __construct($a, $b) {
echo $a+$b;
}
public function sayHello() {
echo 'Hello ';
}
}
trait SayWorld {
public function __construct($a, $b, $c = 0) {
echo (int)$c * ($a+$b);
}
public function sayHello($a = null) {
parent::sayHello();
echo 'World!'.$a;
}
}
class MyHelloWorld extends Base {
use SayWorld;
}
$o = new MyHelloWorld(2, 3);
$o->sayHello(1);
I have an error:
Fatal error: MyHelloWorld has colliding constructor definitions coming from traits
How can I to fix it? You can test my code here.
Try:
Ref: PHP Docs
I think for now the only way to do what you want is:
Edit 2:
My advice, based on over a year of dealing with traits in PHP, is: avoid writing constructors in traits at all, or if you must - at least make them parameterless. Having them in traits goes against the idea of constructors in general, which is: constructors should be specific to a class to which they belong. Other, evolved high-level languages don't even support implicit constructor inheritance. This is because constructors have far more stronger relation to the class then other methods. In fact they have so strong relation, that even the LSP does not apply to them. The traits in Scala language (a very mature and SOLID-friendly successor of Java), can't have a constructor with parameters.
Edit 1:
There was a bug in PHP 5.4.11, which actually allowed to alias a superclass method. But this was considered a no-no by the PHP developers, so we are still stuck with that cumbersome solution which I presented above. But that bug raised a discussion about what can be done with this, and I'm hoping it will be targeted in future releases.
Meanwhile I came across the same problem over and over again. My irritation raised exponentially with the number of parameters and lines of docblock which had to be repeated a lot of times in order to use the trait. So I came up with the following pattern in order to stick to the DRY rule as much as I could:
Instead of repeating entire set of parameters like this:
I write a class much like a tuple (concept familiar to C# and Python users), and use it instead of an endless list of parameters:
Note: this pattern is of course more useful with a larger amount of tuple's constructor parameters, and more classes using the tuple.
It can be automated further with the use of PHP's dynamic nature.