Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61903
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 81.20.134.149 cause and error)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <232501B15F7F4B3197123F219370E36D@pc>
Date: Wed, 1 Aug 2012 08:10:40 +0200
Cc: <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <A9048740-0311-4A3E-AF7A-77650F997790@stefan-marr.de>
References: <232501B15F7F4B3197123F219370E36D@pc>
To: Stan Vass <sv_forums@fmethod.com>
Subject: Re: [PHP-DEV] Traits behavior still up in the air in 5.4
From: php@stefan-marr.de (Stefan Marr)

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:
> =
--------------------------------------------------------------------------=
--
>=20
> trait T {
>    function foo() { $this->bar; }
>    function bar() { echo 'trait'; }
> }
>=20
> class C {
>    use T;
>    function bar() { echo 'class'; }
> }
>=20
> $c =3D new C;
> $c->foo(); // "class"
>=20
> 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.
=46rom 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.
> =
--------------------------------------------------------------------------=
--
>=20
> trait T {
>    function bar() { echo 'trait'; }
> }
>=20
> class C {
>    use T { bar as foo; }
> }
>=20
> $c =3D new C;
> $c->bar(); // "trait"
>=20
> 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.
> =
--------------------------------------------------------------------------=
--
>=20
> trait T1 {
>    private $foo;
>=20
> trait T2 {
>    private $foo;
> }
>=20
> class C { use T1, T2; } // No error.
>=20
> 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.
> =
--------------------------------------------------------------------------=
--
>=20
> 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


--=20
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