Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47629
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 188.40.37.16 cause and error)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <0168C42F-EDBC-48D2-B253-F452E3E67B81@stefan-marr.de>
Date: Thu, 25 Mar 2010 23:37:53 +0100
Cc: David Soria Parra <dsp@php.net>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <C5501455-9287-44E1-ADA3-1BB4F603EFB9@pooteeweet.org>
References: <690D1362-7F1D-47B9-A4BF-EEA9CF38C5B0@pooteeweet.org> <001601cacb74$0b037020$210a5060$@com> <9721DC06-BE10-49D0-BEDA-6B6FEB26B49D@stefan-marr.de> <slrnhqmqdv.382.dsp@experimentalworks.net> <5EE73B98-FC94-4110-BA74-189B547A7ED5@pooteeweet.org> <87B0F854-BB82-4125-84A4-34BD93049760@pooteeweet.org> <D6D25991-7AEA-4BA3-946B-788FA8C01FEB@stefan-marr.de> <0168C42F-EDBC-48D2-B253-F452E3E67B81@stefan-marr.de>
To: Stefan Marr <php@stefan-marr.de>
Subject: Re: [PHP-DEV] horizontal reuse: traits vs. grafts
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 25.03.2010, at 22:59, Stefan Marr wrote:

>=20
> On 25 Mar 2010, at 21:30, Stefan Marr wrote:
>> On 25 Mar 2010, at 16:37, Lukas Kahwe Smith wrote:
>>> Hi,
>>>=20
>>> this was just brought up on IRC. my understanding is that traits =
have no concept of properties, but grafts do (all hidden internally). =
correct?
>> Right, the Traits proposal as it is at the moment, avoids the =
explicit discussion of state.
>> This is not a restriction per se, but could limit the composability =
of traits.
>>=20
>> To ensure composibility, you would have to resort to abstract methods =
which are implemented by the composing class.
> Maybe I should clarify that.
>=20
> Currently the semantics is implicitly the following:
>=20
> class Base{
> var $a;
> }
>=20
> trait T1 {
> var $a;
> var $b;
> }
>=20
> trait T2 {
> var $a;
> var $c;
> }
>=20
> class Composite extends Base {
> use T1, T2;
> }
>=20
> and Composite would have the instance variables $a, $b, $c.
> The problem would be of course that Base, T1, and T2 could use $a for =
completely different things.
>=20
> Simple, but at the cost of composability/safety.
> But for most practical cases that should be 'good enough'. As already =
mentioned, if you want stronger guarantees, state accessor methods can =
be used.
>=20
> However, I think this implication is not discussed in the RFC, and =
works just because PHP can create the fields dynamically. Thus, I used =
'var' here in the example, instead of defining a semantics and handling =
for public, private, protected.


Right, but the issue doesnt go away if I would define a private property =
in the trait. Its still just "stupid" copy paste and so its the job of =
the trait user to ensure that there is no overlap. As such updating the =
trait code can easily break your code, its not encapsulated =
automatically, contrary to grafts. All in all I do see appeal for =
traits, but I think grafts just offer less wtf!?! surprises when code =
around you changes and so I favor grafts and I do not think we need both =
approaches.

So without having tested the patch, I am currently +1 on the grafts =
proposal as its in the wiki.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org