Hello Andi,
i said 'we could probably add'. But even though proxy/aggregation idea
like you offered and which i of course could implement in spl exists i
still see no reason for it. The problem with the latter is that it only
gives you back the original MI problems and doesn't work together with
interfaces at all. Thus i see it as contraproductive. Or in other words
let's simply not add something here and live with code reuse. Unless it
turns out in the future that it becomes the normal thing - by that time we
might have PHP 8 wishlist ;-)
regards
marcus
Wednesday, August 24, 2005, 1:27:20 AM, you 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.
> Andi
> At 12:57 PM 8/23/2005, Marcus Boerger wrote:
>>Hello Zeev,
>>
>>Tuesday, August 23, 2005, 8:59:49 PM, you wrote:
>>
>> > At 19:12 23/08/2005, Lukas Smith wrote:
>> >>Joseph Crawford wrote:
>> >>>I would like to see Multiple Inheritance implemented in a future version.
>> >>>I am not sure what obstacles got in the way (if any) for not implementing
>> >>>that in PHP 5 but i would defenately like to see that in PHP 6 or 7
>> >>
>> >>IIRC, it was shot down. Use overloading and interfaces to get
>> similar effects.
>>
>> > You're right, it was, that's why we have interfaces.
>>
>>Exactly. And you can emulate MI with __call().
>>
>>The only thing we could probably add is delegates to overcome the
>>anti-code-reuse interface aspect.
>>
>>// Some interface
>>interface Printable {
>> function print();
>>}
>>
>>// A general implementation for the interface
>>class PrintHandler implements Printable {
>> function print() { /* ... */ }
>>}
>>
>>// A standard user class that implements the interface. Typically this is the
>>// reason for MI since often you would just go with a standard impl for the
>>// interfaced code. Actually common with containers (*).
>>class Document implements Printable {
>> delegate Printable $print;
>>
>> function __construct() {
>> $this->print = new PrintHandler($this);
>> }
>>
>> // No need to provide function print here - actually doing so is an error
>> // since tit's body is automatically generated as a call to the delegate:
>> // function print() {
>> // if (!$this->print) throw new Exception("Delegate must not be NULL");
>> // $this->print->print();
>> // }
>>}
>>
>>On the one hand this raises the complexity and syntax magic. On the other
>>way it is really elegant and promotes code-reuse which is otherwise a pain
>>with interfaces.
>>
>>(*) Actually the most prominent case is a general Container and a base class
>>in a GUI Framwork. There the desktop and the windows need containers too. So
>>you'd habe an interface to access the container and implement it againa and
>>again...even though you already have it. And if you find a mistake - nobody
>>tells you whether you fixed all incarnations of the code.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
