Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <27.59.64513.8565EB74@pb1.pair.com>
To: internals@lists.php.net
Date: Thu, 21 Feb 2008 22:58:00 -0600
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net>
In-Reply-To: <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: spam.goes.in.here@gmail.com (Joshua Thompson)

Replies to a) and b) below:

Andi Gutmans wrote:
> 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 = 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.
> 

If you read the stateful traits paper Stefan linked to, you can see a 
precedent for how this has been implemented. By default the properties 
are private to the scope of the trait. The client class can also make an 
alias to the property and have access to this property through this 
private alias property. The client class can also merge multiple 
properties into one common properties.

The problem with this is during flattening. When there is a conflicting 
property, all references have to be "alpha-renamed" in all the trait 
methods. This is a more costly operation as compared to the flattening 
of stateless traits. This may not be reason enough not to include it, 
but it should definitely be a consideration.

> 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.
> 	
> 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

Let me use a quote on aliasing from this paper 
<http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf>: "The 
new name is used to obtain access to a method that would otherwise be 
unreachable because it has been overridden." The point of aliasing is to 
give the client class a way to call the old method after it has been 
overridden.

Generally, if two traits have the same method names, you would want to 
alias both of them, override the method, and use the aliases to compose 
the overridden method. The other option is to just choose one of the 
trait's method implementations and exclude all others.

And if you are talking about making the old method that is aliased into 
a method that is private to just that trait, flattening would then 
require some kind of "alpha-rename" for even stateless traits in some cases.

-- 
"Joshua Thompson" <spam.goes.in.here@gmail.com>
<http://www.schmalls.com>