Re: 5.4a2 trait attribute name conflict resolution

Hi: On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky <alex.howansky@gmail.com> 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