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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
