Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35670
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: Wed, 20 Feb 2008 18:26:48 -0800
Message-ID: <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net>
Thread-Topic: [PHP-DEV] RFC: Traits for PHP
Thread-Index: AchxXgPNFA20I9GqSZOVJk073I8+RwC0JEfQ
References: <001c01c87264$3c01b4e0$b4051ea0$@de>
To: <php@stefan-marr.de>,
	<internals@lists.php.net>
Cc: =?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")

Hi Stefan,

Thanks for writing such a good proposal.
In general I think traits is a very interesting idea. I can think of a =
few cases in my life as a programmer where it could have helped me out.

I think some comments re: the syntax/naming are good ones but I prefer =
not to get into naming in this email. I believe we can brainstorm re: =
naming when we figure out exactly what we want to do. I do support =
though finding a way which is simple for non-English speakers but not =
too simple like Perl:)

Thinking back at the times when something like this would have been =
useful to me I think there are a couple of main points I'd like to =
brainstorm about:

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.

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.

I need to put a bit more thought into this but it's an initial attempt =
to provide an additional point of view which may actually give some more =
structure to the proposal while still delivering the benefits of this =
idea.

I think if this kind of idea could be fully baked it would solve the =
problems I have had in the past possibly without the more dangerous =
renaming/removing of functions. I have not looked into feasibility of =
this idea yet.

Anyway, good ideas and thanks for the very professional way you have =
brought this idea to the community.
=09
Let's try and nail down the behavior and then we can have the harder =
naming discussion :) Just saying harder because I've always considered =
naming the hardest part in software engineering...

Andi