Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54153
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
Reply-To: php@stefan-marr.de
Sender: stefan.marr.de@gmail.com
In-Reply-To: <4E29949C.9020209@gmail.com>
References: <4E29949C.9020209@gmail.com>
Date: Sat, 23 Jul 2011 15:55:36 +0200
Message-ID: <CA+2ZKBZTWDPOhvJUYFzqcLJdg=ibPbj54yCSx_zQ8YnDR1KEgQ@mail.gmail.com>
To: Alex Howansky <alex.howansky@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
From: php@stefan-marr.de (Stefan Marr)

Hi:

On Fri, Jul 22, 2011 at 5:17 PM, Alex Howansky <alex.howansky@gmail.com> wr=
ote:
>
> Hello folks,
>
> I've just grabbed 5.4a2 to play with traits. I've found some behaviour wh=
ich
> I'm not sure is a bug, an inconsistency, or a design decision.
>
> Consider a trait and a class that implements it but also overrides both a
> trait method and a trait attribute:
>
> trait foo
> {
> =A0 =A0 public $zoo =3D 'foo::zoo';
> =A0 =A0 public function bar()
> =A0 =A0 {
> =A0 =A0 =A0 =A0 echo "in foo::bar\n";
> =A0 =A0 }
> }
>
> class baz
> {
> =A0 =A0 use foo;
> =A0 =A0 public $zoo =3D 'baz::zoo';
> =A0 =A0 public function bar()
> =A0 =A0 {
> =A0 =A0 =A0 =A0 echo "in baz::bar\n";
> =A0 =A0 }
> }
>
> $obj =3D new baz();
> $obj->bar();
> echo $obj->zoo, "\n";
>
> We get:
>
> in baz::bar
> foo::zoo
>
> It seems this is not correct and that it should be:
>
> in baz::bar
> baz::zoo

After some more thought, my take on this is that those properties are
not compatible, and we do the only simple thing possible and raise an
error as soon as possible, because the trait might have changed to
something that is not compatible with the class and the developer has
to be made aware of that.

While traits do not support state per se, we defined a minimal set of
rules so that the use of properties which conflict in their semantics
breaks as early as possible and noticeable to the developer.
Please refer to
https://wiki.php.net/rfc/horizontalreuse?&#handling_of_propertiesstate
for the exact set of rules defined currently.

These rules (rule 1) define that properties are considered
incompatible if they differ in their initial value.
Thus, the case you see here is, according to the rules defined in the
RFC, a bug.

And after looking at the implementation, it turns out that I just
forgot to check one of the return values of the compare function.
Thus, this is fixed as per
http://svn.php.net/viewvc?view=3Drevision&revision=3D313632

Best regards
Stefan