Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35697
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 21 Feb 2008 10:09:27 -0800
Message-ID: <698DE66518E7CA45812BD18E807866CE014A8F1E@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] RFC: Traits for PHP
Thread-Index: Ach0ZaopgaJEcOnuQEaiy3zgugukowATpBjw
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net> <A8D5F2E2-AAD0-45A7-8BFA-0A95DF42E514@pooteeweet.org>
To: "Lukas Kahwe Smith" <mls@pooteeweet.org>
Cc: <php@stefan-marr.de>,
	<internals@lists.php.net>,
	=?iso-8859-1?Q?Marcus_B=F6rger?= <helly@php.net>,
	=?iso-8859-1?Q?Johannes_Schl=FCter?= <johannes@php.net>,
	"Sebastian Bergmann" <sb@sebastian-bergmann.de>,
	"Alexandre Bergel" <alexandre@bergel.eu>,
	"Falko Menge" <falko.menge@hpi.uni-potsdam.de>,
	"Sara Golemon" <pollita@php.net>,
	<derick@php.net>
Subject: RE: [PHP-DEV] RFC: Traits for PHP
From: andi@zend.com ("Andi Gutmans")

See below:

> -----Original Message-----
> From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]
> Sent: Thursday, February 21, 2008 12:41 AM
> To: Andi Gutmans
> Cc: php@stefan-marr.de; internals@lists.php.net; Marcus B=F6rger;
> Johannes Schl=FCter; Sebastian Bergmann; Alexandre Bergel; Falko =
Menge;
> Sara Golemon; derick@php.net
> Subject: Re: [PHP-DEV] RFC: Traits for PHP
>=20
>=20
> On 21.02.2008, at 03:26, Andi Gutmans wrote:
>=20
> > a)
> > I think Traits should be able to act as a self-contained behavior
> > which can always be expected to work. For example if I want a
> > Counter behavior I would like that not to depend on the properties
> > in the containing class. While I don't think we should enable public
> > nor protected properties in Traits I think allowing for private
> > properties in Traits would come in very handy. It also is no problem
> > when it comes to mangling as we can use the Trait name.
> >
> > class Trait {
> > 	private $counter =3D 0;
> > 	function getNextSerialNumber() {
> > 		return $this->counter++;
> > 	}
> > }
> >
> > I strongly recommend not to support protected/public and not to even
> > get into the discussion of dealing with conflicts of such
> > properties. But I think private is very useful.
>=20
> Of course this could be nice, but I think this is maybe the point
> where one should move to delegate?

I don't think so. I think the value here is not copy&paste but to be =
able to encapsulate some functionality which a class can be decorated =
with. Giving a basic storage mechanism to that would be very beneficial =
in a large amount of uses. Again, I am proposing private storage only =
which would be for internal use-only by the decorating methods.
=20
> > b)
> > I haven't thought this through completely but I think we may want to
> > consider a different model from supporting "removing" and "aliasing"
> > of functions. I think this can create a lot of complications
> > especially in larger works and it'll be write-once code and hard for
> > a newcomer to the code to really understand.
> >
> > I think the main reason to support removing/aliasing of functions is
> > in order to avoid conflicts with other Traits/Class methods. Maybe
> > what we can do is to have only "aliasing" but what it would do is to
> > create a public function with the new name and convert the old
> > function into a private function.
> > Benefits:
> > - Keeps the old code from running predictably without breaking
> > dependencies.
> > - Possibly even allowing some form of "is-a" relationship to
> > continue to be valid (and therefore the interface discussion may
> > even be resolved; at least to a certain level). In the case I faced
> > an is-a relationship (i.e. working instanceof operator) would have
> > been nice.
>=20
> I am probably not seeing the obvious here, but how does making the
> function private solve the naming collisions?

My concern about removing/aliasing functions is that you can really do =
some very funky stuff. It almost takes me back to the spaghetti code =
days where you can jump into code someplace in the middle.=20
My proposal would make Traits a bit stricter and ensure that the =
original interface would still exist after it is aggregated. Either by =
honoring the interface and redefining methods which are consistent with =
the Trait or by leaving the original methods around as privates so that =
they can still reference each other.
I think being able to remove a method which may need to be used by some =
internal method is a bit too chaotic. When you're inheriting large code =
bases it can become complicated to manage.

I very much see the value of Traits but I think we should also consider =
making them a bit stricter.
Btw, the "private property" discussion is different from the 2nd one. =
They are mutually exclusive. The latter idea would give more structure, =
still enforce a contract but should provide the same value. I am not =
convinced it's feasible on an implementation side but I think we should =
first consider it from a functional point of view.

Andi