On Fri, Jul 22, 2011 at 8:41 PM, Jonathan Bond-Caron <jbo...@openmv.com> wrote: > On Fri Jul 22 01:46 PM, Alex Howansky wrote: >> >> Sure, but in this case, I created the conflict intentionally because I >> *want* to override it, and I'm not allowed to like I am with methods. >> Don't you think that's inconsistent? >> > > Agree
I do not agree, because for methods there is for most cases a way around. You can introduce a new alias for the same behavior and use that from the method which is overriding the original method name of the trait. Thus, there is a flexible way to compose behavior, and that is what we do everyday. State how ever, does not come with that property, and the last time we discussed different ideas in that direction they were deemed to be complex. > So that traits can keep their own private state (Ben Schmidt's idea) One of those ideas should definitely be reconsidered for a later version of PHP, but for the moment, I would prefer to concentrate on getting bug-free what we have already and gather some experience on how it is actually used in real-world scenarios. In the end, if you trait is to complex and can 'break' easily, I think that shows that it is worth to be implemented as a class, and you might use instead a trait that provides you with the necessary delegation functions. Best regards Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
