Didn't send to list the first time, please accept my apologies if you
received this twice - Thanks
That makes sense if it would overwrite the methods as well, but otherwise it
seems like it provides inconsistent functionality. Perhaps I'm wrong as
likewise I have a very limited understanding here.
- Mike
-- Past Conversation ---
---------------------------------
In my limited understanding, a trait is sort of composited at compile
time (ish). As properties are dynamic (ish), they will overwrite. Just
like an inherited class will overwrite public properties in their
parent class.
Richard
---------------------------------
I was under the impression that traits were not supposed to have
properties at all:
>From the RFC:
Since Traits do not contain any state/properties, there is a need to
describe the requirements a Trait will rely on. In PHP it would be
possible to utilize the dynamic language features, but it is a common
practice to give this requirements explicitly. This is possible with
abstract methods like it is used for abstract classes.
Is the support for properties the bug perhaps?
Anthony
---------------------------------
Hello folks,
I've just grabbed 5.4a2 to play with traits. I've found some behaviour which
I'm not sure is a bug, an inconsistency, or a design decision.
Consider a trait and a class that implements it but also overrides both a
trait method and a trait attribute:
trait foo
{
public $zoo = 'foo::zoo';
public function bar()
{
echo "in foo::bar\n";
}
}
class baz
{
use foo;
public $zoo = 'baz::zoo';
public function bar()
{
echo "in baz::bar\n";
}
}
$obj = new baz();
$obj->bar();
echo $obj->zoo, "\n";
We get:
in baz::bar
foo::zoo
It seems this is not correct and that it should be:
in baz::bar
baz::zoo
The traits RFC pretty clearly states that if a class method conflicts with a
trait method then the trait method will be ignored, which is what's
happening, but it says nothing about what happens to attributes in that same
condition. Is this a bug?
Alex
