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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php