Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51062
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=QGaJl06BWXDRxWnbiAZ2ogjywOtOezqunymO1/Jb5mvD63tHsckXIcN1sWPuB7JIDF
         Xk5zJwgRQoY/P9807OJkaKuNoWiH6XtDaCsSIJ7fVxf2X0+aj+4eIxLZSljz1uKch7RD
         vgLl4qo8wYLRDz1g73+mgBBwBDAFmaBOsmCuA=
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <581ACCE6-71A4-444F-A226-8D87E1B43EEF@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de>
	<581ACCE6-71A4-444F-A226-8D87E1B43EEF@stefan-marr.de>
Date: Thu, 16 Dec 2010 22:05:24 +0100
Message-ID: <AANLkTi=iJ5zT0451CyFG6GXVyQfqP3t+Wea9Dyvu6raP@mail.gmail.com>
To: Stefan Marr <php@stefan-marr.de>
Cc: "internals@lists.php.net Development" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Traits and Properties
From: patrickallaert@php.net (Patrick ALLAERT)

2010/12/16 Stefan Marr <php@stefan-marr.de>:
> Hi:
>
> From my point of view the right thing to do with regard to properties is =
defined in the test cases below.
>
> The rational behind providing this semantics is based on the fact that PH=
P allows to define properties dynamically anyway, so there is no way around=
 properties.
> However, there should be a way that a developer can notice that the code =
might not behave as expected in the composed class.
>
> It is true that behavior needs state to operate on, however, accessors ar=
e a common pattern and fully supported by traits. Furthermore, traits are n=
ot supposed to replace classes, and when a trait does more than just provid=
ing code that is to be easily reused, then the designed should ask the ques=
tion whether that is not actually a class, which then provides the necessar=
y guarantees to enforce the invariances the code expects.
>
> Thus, I would like to keep traits as a lightweight concept for code reuse=
.
>
> Best regards
> Stefan
>
> --TEST--
> Conflicting properties should result in a notice.
> Property use is discorage for traits that are supposed to enable maintain=
able
> code reuse. Accessor methods are the language supported idiom for this.
> --FILE--
> <?php
> error_reporting(E_ALL);
>
> trait THello1 {
> =C2=A0public $foo;
> }
>
> trait THello2 {
> =C2=A0private $foo;
> }
>
> class TraitsTest {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0use THello1;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0use THello2;
> }
>
> var_dump(property_exists('TraitsTest', 'foo'));
> ?>
> --EXPECTF--
> Notice: Trait THello1 and THello2 define the same property in the composi=
tion of TraitsTest. This might be incompatible, to improve maintainability =
consider using accessor methods instead. Class was composed in %s on line %=
d.

In this test, you might want to display some text before the
var_dump() (or alternatively to hardcode the line number on last line)
to ensure it is the property_exists() function call or the class
definition which would create such a notice.

Regards,
Patrick

--=20
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor