Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35710
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 82.96.83.42 cause and error)
Message-ID: <47BE0664.8060304@stefan-marr.de>
Date: Fri, 22 Feb 2008 00:16:52 +0100
Reply-To: php@stefan-marr.de
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Andi Gutmans <andi@zend.com>,
	Internals Mailing List <internals@lists.php.net>
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: php@stefan-marr.de (Stefan Marr)

Hi,

Andi Gutmans schrieb:
> 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.
Sounds a bit like what had been proposed in this paper: 
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca07b-FreezableTrait.pdf

The first point, yes exclusion and aliasing are only meant to handle 
conflicts, and should be used only in this context. Yeah you can break 
the trait with it, but you did it explicitly, think this should be made 
clear a bit more in the discussion about "breaking interfaces".

Nobody would request unset to be removed from the function set even 
though you can do this:

$a = new A();
unset($a);
$a->foo();  //damn...

It is "almost" like excluding a method from a trait and be worried about 
  the trait breaks. Isn't it? :)

> Benefits:
> - Keeps the old code from running predictably without breaking dependencies.
Well, in the code I've read so far, exclusion has been used to 
cog/dovetail to traits which supplement each other very well.

> - 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.
Hm, I would prefer to not add the type notion to traits. They are only 
units of reuse, not types IMHO.

> 
> 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.
Think user-changeable location of composed methods is quite possible, 
but for the cost of complexity. (Have a look at the paper for the 
complete idea of trait-local/freezed methods.)

Kind Regards
Stefan