Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35726
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: Fri, 22 Feb 2008 13:44:13 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <1985981545.20080222134413@marcus-boerger.de>
To: Lukas Kahwe Smith <mls@pooteeweet.org>
CC: php@stefan-marr.de, Evert|Rooftop <evert@rooftopsolutions.nl>, 
	"Stanislav Malyshev" <stas@zend.com>, <internals@lists.php.net>
In-Reply-To: <9EE7F229-0710-48E8-9A26-DC8031AF8979@pooteeweet.org>
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> <9EE7F229-0710-48E8-9A26-DC8031AF8979@pooteeweet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Traits for PHP
From: helly@php.net (Marcus Boerger)

Hello Lukas,

  alright,

   'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should really be
something that only marks a method as private if at all. That can be
done as:
   'foo as private' since private is a keyword it cannot conflice anyway.

marcus

Wednesday, February 20, 2008, 9:52:56 PM, you wrote:

> 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



Best regards,
 Marcus