Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35666
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: "Marcus Boerger" <helly@php.net>,
 Evert|Rooftop <evert@rooftopsolutions.nl>,
 "Stanislav Malyshev" <stas@zend.com>,
 internals@lists.php.net
Message-ID: <9EE7F229-0710-48E8-9A26-DC8031AF8979@pooteeweet.org>
To: php@stefan-marr.de
In-Reply-To: <1e12984d0802201243gfa51f01i311891e8965ed51e@mail.gmail.com>
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: Wed, 20 Feb 2008 21:52:56 +0100
References: <001c01c87264$3c01b4e0$b4051ea0$@de> <173732199.20080219175837@marcus-boerger.de> <1203452909.24580.9.camel@localhost> <1e12984d0802191323o710c6b8ej3a54af7901cf35f1@mail.gmail.com> <47BB4AC9.9070701@zend.com> <1e12984d0802191346x7c145d7fp14c01ec4e5993779@mail.gmail.com> <47BB4F49.1030904@rooftopsolutions.nl> <1e12984d0802191359p4f21c3acrdff4b86adfb4bf3@mail.gmail.com> <1495054633.20080220205951@marcus-boerger.de> <1e12984d0802201243gfa51f01i311891e8965ed51e@mail.gmail.com>
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.134, required 6, AWL 0.03, RDNS_DYNAMIC 0.10)
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 20.02.2008, at 21:43, Stefan Marr wrote:

>> If we feel it gets necessary we probbaly
>> might want to support a syntax like:
>> 'trait_method' => false
>> 'trait_method' => 'new_name'
>> 'trait_method' => array('new_name', 'trait_method'
> I'm not comfortable with this notation, since it strengthens the
> impression that it is renaming.
>
> In my eyes it looks like this:
>
> "trait_method => false" means trait_method is moved to false, it is
> deleted, but this leads to the wrong impression of this:
> "trait_method => new_name" means trait_method is moved to new_name,
> and I am absolutely against this notion.
>
> Renaming implies in my opinion all references to this method might be
> adjusted (what is not possible at all) and the original method is
> "lost".
> There are several problems with with "lost" method already discussed
> on this list, like not fulfilled requirements (the delete method
> thing).
>
> The aliasing notion has the benefit that a method has to be explicitly
> excluded to be removed. So the developer explicitly requests for a
> change that he will handle on its own.

I agree that its important to make this concept clear in the syntax  
and that Marcus's proposal does not make it sufficiently clear.

I do like Lars' proposal however:
I have another syntax proposal:
class Foo {
   consume TFoo {
      methodName as newMethodName;
      ignore otherMethod;
   }
}

maybe "as" should even be expanded to "alias"

though the following does look like the english grammar police will  
get us:
methodName alias newMethodName;

regards,
Lukas