Re: RFC: Traits for PHP

From: Date: Wed, 20 Feb 2008 20:01:27 +0000
Subject: Re: RFC: Traits for PHP
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-35654@lists.php.net to get a copy of this message
Hello Jochem, good arguments. And good ideas. I'd favor 'posesses' then. marcus Tuesday, February 19, 2008, 9:54:09 PM, you wrote: > firstly, I'd like to reiterate the general sentiment > that Stefans RFC is blinding! (that's a good thing in this context ;-) > Marcus Boerger schreef: >> Hello Lars, >> >> we could even go for include here if we wanted to avoid use as much as >> adding a new keyword. Personally I don't mind using keywords for different >> stuff as long as it cannot conflict. That is in this case true for both >> include and use. > how about 'possesses' or 'exhibits' - both these words are closer to the > natural language usage of 'trait' with regard to a subject. > John exhibits a **** trait > Jack possesses a **** trait > a person coming accross 'use' or 'include' in the context of > trait attribution may either make assumptions or become confused as to > possible changes/additions to the use and/or include functionality, a > new keyword that aptly describes the intention will more likely force > users to actually find out what it means. > an another alternative might be 'applies' - which doesn't fit the > natural language usage of 'trait' but does succintly describe what is happening. > just a thought. >> >> marcus >> >> Tuesday, February 19, 2008, 9:31:29 PM, you wrote: >> >>> Hi Stefan, >> >>> Am Montag, den 18.02.2008, 20:27 +0100 schrieb php@stefan-marr.de: >>> [...] >>>> class ezcReflectionMethod extends ReflectionMethod { >>>> use ezcReflectionReturnInfo; >>>> /* ... */ >>>> } >> >>> I'm not sure if the use-keyword is a good idea as namespaces are already >>> "used". If we use "use" for traits, maybe going back to >>> "import" for >>> namespaces would be the way to go. >> >>> cu, Lars >> >> >> >> Best regards, >> Marcus >> Best regards, Marcus

« previous php.internals (#35654) next »