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