Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47623
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <D6D25991-7AEA-4BA3-946B-788FA8C01FEB@stefan-marr.de>
Date: Thu, 25 Mar 2010 22:59:43 +0100
Cc: Lukas Kahwe Smith <mls@pooteeweet.org>,
 David Soria Parra <dsp@php.net>,
 internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <0168C42F-EDBC-48D2-B253-F452E3E67B81@stefan-marr.de>
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>
To: Stefan Marr <php@stefan-marr.de>
Subject: Re: [PHP-DEV] horizontal reuse: traits vs. grafts
From: php@stefan-marr.de (Stefan Marr)


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.

Currently the semantics is implicitly the following:

class Base{
 var $a;
}

trait T1 {
 var $a;
 var $b;
}

trait T2 {
 var $a;
 var $c;
}

class Composite extends Base {
 use T1, T2;
}

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.

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.

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.

Best regards
Stefan


>=20
> Best regards
> Stefan
>=20
>=20
>=20
> --=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
>=20
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20

--=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