Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61901
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fmethod.com from 209.85.212.182 cause and error)
Message-ID: <232501B15F7F4B3197123F219370E36D@pc>
To: <internals@lists.php.net>
Date: Wed, 1 Aug 2012 02:23:57 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0018_01CD6F8C.B411C360"
Subject: Traits behavior still up in the air in 5.4
From: sv_forums@fmethod.com ("Stan Vass")

------=_NextPart_000_0018_01CD6F8C.B411C360
Content-Type: text/plain;
	charset="windows-1251"
Content-Transfer-Encoding: quoted-printable

I'd like to point out some puzzling behaviors in Traits as they exist in =
the production releases of PHP 5.4.

-------------------------------------------------------------------------=
---
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 =3D new C;
$c->foo(); // "class"

Proposed behavior: Fatal error on collision, unless the method is =
imported with a unique name using the { ... as ... } syntax.

-------------------------------------------------------------------------=
---
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 =3D 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.

-------------------------------------------------------------------------=
---
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.

-------------------------------------------------------------------------=
---
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.

Not many use 5.4 yet, so the sooner all this is clarified, the better, =
before it becomes completely unfixable due to BC. Feedback?

Stan
------=_NextPart_000_0018_01CD6F8C.B411C360--