Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35706
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: <47BDFED6.4030303@stefan-marr.de>
Date: Thu, 21 Feb 2008 23:44:38 +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>
Cc: 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 - Stateful Traits
From: php@stefan-marr.de (Stefan Marr)

Hi,

Andi Gutmans schrieb:
> 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.
Hope I got it right, since your example is a class?

Ok, stateful traits are useful in the sense of having self-contained 
units of reuse. Personally, I prefer them over stateless traits.
But, here we will get additional confusion.

You don't like to handle with visibilities of properties? Fine :)
One way to do stateful traits is described in 
http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07eStatefulTraits.pdf

But the way you have proposed is stricter and may be sufficient.

To avoid confusion and misconception I would like to change your 
proposal a bit. Private does suggest a semantics like methods, and would 
require to apply the flattening on properties like on methods. Since we 
do not like to handle conflicts, this would have to be done a bit 
different, in my opinion.

Let's change ``private`` to ``local``:
trait TCounter {
   local $counter = 0;
     function getNextSerialNumber() {
     return $this->counter++;
   }
}

class Website {
   use TCounter;
}

The resulting composition would have a property resulting from the 
TCounter property, but is only accessible from a method of the specific 
trait, i.e., it is composition local.

Just an additional though :)

Kind Regards
Stefan