Re: Traits behavior still up in the air in 5.4

Dear Stan: On 01 Aug 2012, at 01:23, Stan Vass wrote: > ---------------------------------------------------------------------------- > 1. Name collisions between a trait method and a class method using the trait go unreported, the > class silently shadowing the trait method: > ---------------------------------------------------------------------------- > > trait T { > function foo() { $this->bar; } > function bar() { echo 'trait'; } > } > > class C { > use T; > function bar() { echo 'class'; } > } > > $c = new C; > $c->foo(); // "class" > > Proposed behavior: Fatal error on collision, unless the method is imported with a unique name > using the { ... as ... } syntax. This happens to be 'by design'. The methods in the class have *always* higher precedence. This is the same 'overriding' behavior used for inheritance. From my personal perspective, changing this would lead to a major inconsistency with how subclassing works. If you disagree, please open an explicit thread for this problem and report it in the bug tracker. > ---------------------------------------------------------------------------- > 2. Using "as" syntax when importing a trait does NOT rename a method, but creates an > alias CLONE, the original method still callable. > ---------------------------------------------------------------------------- > > trait T { > function bar() { echo 'trait'; } > } > > class C { > use T { bar as foo; } > } > > $c = new C; > $c->bar(); // "trait" > > Proposed behavior: the original name should be only accessible within the trait and its > methods, not from the class methods or by calling the class instance's methods from outside. Again, this happens to be 'by design'. PHP is a rather dynamic language, and we happen to have things like $c->$foo(); where $foo is a string. Renaming is technically not reasonable, and would also lead to major confusion when metaprogramming is used. Bye the way, this is documented: https://wiki.php.net/rfc/horizontalreuse#renaming > ---------------------------------------------------------------------------- > 3. Properties silently collide in traits and classes. > ---------------------------------------------------------------------------- > > trait T1 { > private $foo; > > trait T2 { > private $foo; > } > > class C { use T1, T2; } // No error. > > Proposed behavior: An error is produced only when the properties differ in visibility or a > default value, which is clearly insufficient to determine they're used for the same purpose, > and hold the same data. Instead they should use the same logic as method conflicts: fatal error on > name collision. Alternatively, each trait property whould be accessible within the trait that > defines it, not from other traits used in the same class, or the class itself. Please read https://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate carefully. Again, this is intended behavior. If you want to be notified of such collisions, please use E_STRICT. > ---------------------------------------------------------------------------- > 4. The documentation says static propeties can't be defined by traits. Yet they can. > ---------------------------------------------------------------------------- > > I don't know what's the bug here: a doc bug, or a code bug. For consistency, static > properties should work, if instance properties work. Nothing is gained supporting it half-way. Could you please point me *exactly* to the paragraph where we have something written about static properties? I do not see that I wrote anything special about static properties in the RFC. And I do not find it in the docs either. static properties should work like normal properties. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525