Re: PHP 6.0 Wishlist

Well $proxy would automagically support the interfaces of the aggregated objects. And if there's a method you want to proxy to one rather the other you could fine tune that. Anything more than that would be getting into an OOP pissing contest which I don't feel like getting into, as it would be academic and wouldn't be suitable for the PHP audience... Andi At 03:43 PM 8/24/2005, Marcus Boerger wrote:

Hello Andi, hu? Here's you example again: <?php $proxy = new Proxy() $proxy->aggregate($obj2); /* Also aggregates interfaces */ $proxy->aggregate($obj3); $proxy->delegate($obj3, "method_that_exists_in_both_objects"); ?> ok lets change this to an interface like in my example: <?php interface Printable { function print(); } class Document extends Proxy implements Printable { // now you need to implement the functions of Printable, only how? // implement them as empty and later overload them with their real body? } ?> So what do you want to do about the fact that my delegates are done at compile time while your aggregation is run at compile time? And no, at the moment there is absolutley no way than to completley rewrite the object/interface stuff in php to allow dynamic interfaces which your proposal would need become compatible. And even if you did you'd simply overthrow the idea of interfaces, wouldn't you? best regards marcus Thursday, August 25, 2005, 12:35:11 AM, you wrote: Not if it's done they way I think it can be done... At 03:17 PM 8/24/2005, Marcus Boerger wrote:

Hello Andi, you mean fine tune the 'protocol' to use the correct wording.

It simply is

incompatible with the interface concept. Wednesday, August 24, 2005, 11:48:33 PM, you wrote:

I don't mind not adding it, as long as we don't add "delegate" :) Anyway, it's different from MI because it allows you to fine tune the interface... Andi

At 12:01 PM 8/24/2005, Marcus Boerger wrote:

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.