'Simple' phpers idea about interfaces/code reuse [was] Re: [PHP-DEV] PHP 6.0 Wishlist

Andi Gutmans wrote:

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...

in a totally non-academic and impure way I have always thought that it would be nice to be able to define function bodies in interface declarations ... I realise that every computer science major is now screaming 'no' but from a practical phper's POV it seems efficient to be able to say: interface Printable { function print() { // do simple generic stuff here // maybe go wild with some reflection :-) } } I would see this as a optional addition to the syntax of interfaces... i.e. everything works as before but you can add default function bodies which would behave as if it was defined in each class that implements the given interface. IMHO interfaces would be a stronger tool because of the increased code reuse, I find interfaces a very nice addition but I'm sometimes miffed at the need to redefine an identical function X times (in situations where there are already class hierarchies that do not lend themselves to incorporating the 'interface' implementation in some base class). if this is a truely evil concept I would very much appreciate a little heads up as to why :-) rgds, Jochem ps. and again (hey I'm a broken record too!) thanks for php! Pretty Happy Punter.

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.