Hi Larry, > So if the Trait is not stateful, what is the advantage over delegation? That > was cited in an earlier email as a shortcoming of delegation, but if the > Traits > implementation doesn't address it either except through a getter/setter, then > it's still functionally equivalent to delegation. Think the difference is not the functional part here but the conceptional goal which is achieved.
Delegation has still a strong right to exist even with traits. The idea of delegation is to reuse a complete entity. May be not the best example but still a good one is the OO Stack build from a linked list. You did like to reuse the list as a container for the stack data. It is full-fledged object here, which will do something for you. But in situations where you have a strong coherence of the state and the behavior you need and the state may consist of several properties, the natural thing would be to implement the behavior in a method in this class, because delegation would require you to make this properties accessible by getters/setters or have methods with many parameters. Here the real question is, does the delegate has a right to exist without this client? Are there any other clients using this class, or is it more appropriated to merge it directly into this class? This questions could only be answered seriously for a specific case. Traits are meant to simplify the code reuse for single methods or groups of methods while delegation allows reuse of complete autonomous entities. Well, think the above is only true in a world of perfect design ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
