Re: 5.4a2 trait attribute name conflict resolution
Hi:
On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky <[email protected]> wrote:
>
> 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
After some more thought, my take on this is that those properties are
not compatible, and we do the only simple thing possible and raise an
error as soon as possible, because the trait might have changed to
something that is not compatible with the class and the developer has
to be made aware of that.
While traits do not support state per se, we defined a minimal set of
rules so that the use of properties which conflict in their semantics
breaks as early as possible and noticeable to the developer.
Please refer to
https://wiki.php.net/rfc/horizontalreuse?&#handling_of_propertiesstate
for the exact set of rules defined currently.
These rules (rule 1) define that properties are considered
incompatible if they differ in their initial value.
Thus, the case you see here is, according to the rules defined in the
RFC, a bug.
And after looking at the implementation, it turns out that I just
forgot to check one of the return values of the compare function.
Thus, this is fixed as per
http://svn.php.net/viewvc?view=revision&revision=313632
Best regards
Stefan
Thread (18 messages)