+1 from me too please ;)
Indeed the proposed RFC for traits is a wonderfull thing for things we
currently do using mixins.
What's goining on with traits anyway? Has it been decided if it's gonna be
implemented in 5.3, 6.0, 7.2 or never? :)
G.
On Sat, Jul 26, 2008 at 6:27 AM, Andru Vallance <[EMAIL PROTECTED]>wrote:
> Hi
> I just want to add a big +1 from an "end user" perspective for traits.
>
> I know from my perspective this would be an incredibly valuable tool for
> php. I'm essentially already using the functionality this brings (as I'm
> sure many other devs are), albeit in an ugly way - either adding
> functionality to a single superclass at the bottom of the class heirarchy,
> or using interfaces along with composites/delegation, which means a lot of
> unnecessary code duplication.
>
> I've been reading through the threads on the subject -- I'm not sure if
> discussion has died because of pressure to get 5.3 out of the door, or for
> other reasons, but it seems the conversation stopped without any real
> resolution, and the wiki seems to be in a similar state.
>
> It's a great idea in principle, but I've noticed a lot of discussion is
> focused on preventing collisions by ignoring/aliasing methods. Maybe I'm
> misunderstanding the usage case for traits here, but I envision them as
> "working interfaces". The methods of a trait surely shouldn't change
> visibiliy/name depending on which class they appear in? Doesn't that defeat
> the whole point?
>
> Regarding collisions, If I try to do the following...
>
> interface i1{ public function foo(); }
> interface i2{ protected function foo($a,$b); }
> interface i3{ public function foo($a,$b,$c,$d); }
> class Broken implements i1,i2,i3{ private function foo($a) }
>
> .... I wouldn't expect it to work! It's the developer's job to know the
> interface they're implementing. Similarly isn't it the developer's job to
> know the methods in a trait, and manage any collisions directly in their
> code, not in statements for php to process and include/exclude/alias things?
> Moreover, surely it's the developer's responsibility to use verbose method
> names (eg 'saveOrder', not 'save'), in the knowledge that the code will be
> inherited by a class in which his 'save' method would no longer have any
> context, and is likely to collide with existing methods of that class...
>
> My use scenario for a trait would basically be a functional interface...
> Since most of the code so far in the discussion on traits has been all foo's
> and bar's, I'd like to present a few real-life examples that I think show
> the potential use of traits while still keeping the code compact...
>
> trait Optionable{
> protected $_options;
> protected function _setOptions($options){
> $this->_mergeArrays($this->_options,$options) }
> public function getOptions(){ return $this->_options; }
> private function _mergeArrays($ar1,$ar2){ }
> }
> trait Hookable{
> private static $registry;
> public static function registerHook($type,$object){
> self::$registry['...etc...'] } //if methods are copied, I guess it'd have to
> be Hookable::$registry
> protected function _runActionHooks($data){}
> protected function _runFilterHooks($data){}
> }
> class Something is Optionable, Hookable{
>
> //$_options is a protected property of Optionable, so I expect to
> inherit or have a copy...
> //$registry is private so I don't expect to see it here
>
> public function __construct($data,$options){
> //the following methods are all protected, so I'd expect to
> inherit or have them copied with the same visibility
> $this->_setOptions($options);
> $this->_runActionHooks($data);
> $data = $this->_runFilterHooks($data);
> }
> }
>
> I know this basically resembles multiple inheritance (please don't cry)...
> I think the important distinction is firstly one of use - the keyword
> distinction between class and 'trait' should be used to encourage short,
> reusable bits of code, where multiple inheritance and the sloppy behaviour
> that comes with it is not a problem. Secondly, to prevent it becoming
> multiple-inheritance-by-another-name I don't believe traits should be able
> to inherit from other traits.
>
> I've read through every message on this subject and I still don't see the
> benefit being added by all the complexity of adding loads of extra reserved
> words & complex include/exclude/alias logic for something which should
> surely be a simple fix to a simple problem?
>
> If I'm being naiive and totally missing something, please let me know!
>
> Andru
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
