Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35817
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: <47C574A9.1050600@stefan-marr.de>
Date: Wed, 27 Feb 2008 15:33:13 +0100
Reply-To: php@stefan-marr.de
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Lukas Kahwe Smith <mls@pooteeweet.org>
Cc: 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>
In-Reply-To: <4AE8AABE-167C-4705-9EA8-3987121A96EE@pooteeweet.org>
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: php@stefan-marr.de (Stefan Marr)

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