Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35783
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Mon, 25 Feb 2008 10:49:51 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <342791187.20080225104951@marcus-boerger.de>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: Andi Gutmans <andi@zend.com>, php@stefan-marr.de, internals@lists.php.net, 
	=?iso-8859-15?Q?Marcus_B=F6rger?= <helly@php.net>, 
	=?iso-8859-15?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>
In-Reply-To: <A8D5F2E2-AAD0-45A7-8BFA-0A95DF42E514@pooteeweet.org>
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net> <A8D5F2E2-AAD0-45A7-8BFA-0A95DF42E514@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: helly@php.net (Marcus Boerger)

Hello Lukas,

Thursday, February 21, 2008, 9:41:10 AM, you wrote:


> 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?

Private classes are from a users perspective bound to the implementing
class. That would be the Trait. And from a compiler/executors point of view
they are prefixed with the implementing class. That would be the Ttrait as
well. So three functions f, one of Trait a, one of Trait b and one of the
class C itself would all have different names and would all resolve. But
sure they would scare the hell for any user so lets not do any of this. For
the sake of clarification here comes anyway:

Trait a {
  function f() {}
}

Trait b {
  function f() {}
}

class c {
  uses a, b;
  function f() {}
}

Reflection(c):
function "\0a\0f"   function a::f
function "\0b\0f"   function b::f
function "f"        function f

All nicely callable using array syntax:
class d extends c {
   function t() {
     call_user_func(array($this, "a::f")):
     call_user_func(array($this, "b::f")):
     call_user_func(array($this, "f")):
   }
}
$o = new c:
$o->test();

Best regards,
 Marcus