Pull Requests

History

Hi, dmitry, could you please look at this? thanks
the problem occurrs in zend_traits_merge_functions. in that function, it will
unique the trait methods name.
the fix will be a big change, since we should re-implemention the whole merge
functions mechanism, maybe add the tarit name as a suffix to method name.
thanks

and if the class have no own func method defination, the result will be:
<?php
trait T1 {
public function func() {
echo "From T1\n";
}
}
trait T2 {
public function func() {
echo "From T2\n";
}
}
class Bar {
use T1 {
func as f1;
}
use T2 {
func as f2;
}
}
PHP Fatal error: Trait method func has not been applied, because there are
collisions with other trait methods on Bar in /tmp/1.php on line 21
this should also be a bug. thanks :)

@laruence it is intended behavior to have no fatal error in this case.
The method of the class has precedence and solves the conflict explicitly.
If the class does not define a method with that name, the conflict remains
unsolved, and you will get an error.

I would say it's not an implementation bug, but design mistake that allows ambiguous syntax.
The problem that class may include several "use" statements, each statement may refer several traits and each such statement may be followed by a block with alias declarations. However, all these blocks have equal rights and it doesn't mean which traits were used in "use" statement before.
So the second example is treated as:
use T1, T2 {
func as f1;
func as f2;
}
To refer to the proper traits methods need to be qualified
use T1, T2 {
T1::func as f1;
T2::func as f2;
}
I'll try to take a look, if it's possible to fix it, but I don't think it's possible to do it in 5.4 (without binary compatibility break).

Sorry, I don't have the time to look into the code.
But I guess, I compiled the 'as' of 'use T1 { func as f1; }' without the
information of being related to T1.
If the compilation step would automatically add the T1 to 'as' for 'use'
statements with only a single trait, this particular bug here would be solved.
It does not solve the ambiguity however.
Not sure what to do with that.
I still think it is convenient, to be able to leave out the T1:: infront of the
method name.

I agree that syntax "use T1 {func as f1;}" where "func" belong to another trait looks unnatural, and it's better to interpret "func" as "T1::func" in this case, but it won't solve the problem in general, because it's possible to refer few traits in a single "use" statement.