Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35819
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <47C5788C.2020606@iamjochem.com>
Date: Wed, 27 Feb 2008 15:49:48 +0100
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: php@stefan-marr.de
CC: Lukas Kahwe Smith <mls@pooteeweet.org>, 
 Gregory Beaver <greg@chiaraquartet.net>,
 internals Mailing List <internals@lists.php.net>, 
 Marcus Boerger <helly@php.net>
References: <47C317F4.2080301@stefan-marr.de> <47C3854B.1000303@chiaraquartet.net> <4AE8AABE-167C-4705-9EA8-3987121A96EE@pooteeweet.org> <47C574A9.1050600@stefan-marr.de>
In-Reply-To: <47C574A9.1050600@stefan-marr.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: How to build a real Trait thing without exclusion
 and renaming
From: jochem@iamjochem.com (Jochem Maas)

Hi,

I had a thought about recursion (and self referencing) inside trait defined
functions and the possible issues that might occur due to explicit/implicit
conflict resolution and or aliasing/renaming (i'm not completely
following what the status quo is regarding conflict resolution and/or
aliasing and/or renaming, but it seems all share issues to some degree)

if you wish to ensure that a trait's method specifically *always* calls
a method also defined in the same trait maybe syntax like the following could
be used:

trait Foo {
	function A($x) {
		if ($x > 0) trait::A($x--);
	}
	
	function B() {
		trait::A(2);
	}

	function C() {
		self::B();
	}
}

here 'trait::' would tell the compiler to always use the actual method
from the trait in question (no idea how this would work in the guts of the
engine ... apologies for my ignorance :-) and 'self::' would refer to whatever
the method in question is as defined in the flatten, resulting class ...
so that 'self::B()' would call 'B()' as defined in the trait only if it wasn't
aliased/renamed/overloaded in the flatten, resulting class using said trait.

again I'm a little lost as to where the concept is at/going with regard to
aliasing/renaming/conflict-resolution ... but afaict the idea for 'trait::'
possibly offers a way out of potential problems (for the developer of a trait)
in any case.

thanks for listening ... sorry for the noise (if it is noise ... Stefan, Lukas please
be the judge :-)

rgds,
Jochem

Stefan Marr schreef:
> Lukas Kahwe Smith schrieb:
>>> class Talker {
>>>  use A, B, C, D {
>>>    smallTalk = A::smallTalk; // this says that if B, C or D implement
>>> smallTalk, it is ignored
>>>    talk = A::bigTalk;
>>>  }
>>> }
>>
>> Well this is not just a different syntax, but an entirely different 
>> approach. In Stefan's proposal one had to explicitly handle every 
>> conflict manually. in your proposal you do not have to do this.
> I share this objection. Maybe a somewhat handier solution of my proposal 
> would be the option to leave out the method name, but I'm not quite sure 
> whether it is really readable:
> 
> class Talker {
>   use A, B, C, D {
>      B::smallTalk instead A, C, D; //to be read like: use B::smallTalk
>                              // instead the implementations form A, C, D
>    }
>  }
> 
>> BTW Stefan: Whats the syntax for when you want to override a trait 
>> method with one inside the class definition?
>>
>> I guess one would use "self::" like so:
>>
>> class Talker {
>>  use A, B {
>>     B::smallTalk instead A::smallTalk;
>>     self::bigTalk instead B::bigTalk, A::bigTalk;
>>     A::bigTalk as talk;
>>   }
>>
>>   function smallTalk() {
>>   }
>> }
> Hm, personally, I would leave this out. The notion is that class 
> definitions will override trait methods in any case (even/especially if 
> traits methods are conflicting). So it would be fine to have this one 
> implicit. This would also avoid construction attempts like: A::bigTalk 
> instead self::bigTalk, A::bigTalk;
> 
> Kind Regards
> Stefan
>