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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
