Re: PHP 6.0 Wishlist
| From: | Greg Beaver | Date: | Wed, 24 Aug 2005 02:39:40 +0000 |
| Subject: | Re: PHP 6.0 Wishlist | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-18333@lists.php.net to get a copy of this message | ||
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