Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35679
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
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>
Message-ID: <A8D5F2E2-AAD0-45A7-8BFA-0A95DF42E514@pooteeweet.org>
To: Andi Gutmans <andi@zend.com>
In-Reply-To: <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 21 Feb 2008 09:41:10 +0100
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.045, required 6, AWL 0.04)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: mls@pooteeweet.org (Lukas Kahwe Smith)


On 21.02.2008, at 03:26, Andi Gutmans wrote:

> 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.

Of course this could be nice, but I think this is maybe the point  
where one should move to delegate?

> 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 am probably not seeing the obvious here, but how does making the  
function private solve the naming collisions?

regards,
Lukas