Andi Gutmans wrote: > Again (I sound like a broken record), I don't think that we should add > language constructs to support delegation. We will be overcomplicating > things for PHP developers and it'll start to be hard to read PHP code. > I do think it might be worth considering a user-land or internal class > such as a Proxy class which would allow the advanced user to have more > find-grained control on delegation. > I'd still keep it simple. So basically I'd allow aggregating objects (or > delegatees), and define their priority in the order they are added. Then > there could be one method which overrides this priority by allowing to > map methods to objects. For example something like: > > $proxy = new Proxy() > $proxy->aggregate($obj2); /* Also aggregates interfaces */ > $proxy->aggregate($obj3); > $proxy->delegate($obj3, "method_that_exists_in_both_objects"); > > This would only be used in very advanced cases, most probably in > frameworks but would be invisible to the average PHP developer. > Complicating it more than this including the addition of language > constructs doesn't seem good to me. If this isn't enough (and I"m sure > there are some hypothetical cases where it might not be), then you could > achieve the same goal in other ways... > > Still I am torn wether even this should be added.
I haven't investigated the code deeply (read: haven't yet used it in a project), but PEAR_Delegator is designed to handle this, and might be an interesting starting point for an internal class should this end up in spl or somewhere along those lines. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
