Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:18447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 25 Aug 2005 22:51:26 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <5269680.20050825225126@marcus-boerger.de>
To: =?ISO-8859-15?Q?Oliver_Gr=E4tz?= <oliver.graetz@arcor.de>
Cc: internals@lists.php.net
In-Reply-To: <430E2A6A.2070803@arcor.de>
References: <430E2A6A.2070803@arcor.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Just some feedback on MI
From: helly@php.net (Marcus Boerger)

Hello Oliver,

  the short answer is we don't want virtual inheritance.

marcus

Thursday, August 25, 2005, 10:30:34 PM, you wrote:

> Hello gods of PHP development ;-)

> I'm just a PHP-programmer, but I've been reading the PHP6 discussions
> here for a while, especially the talk about MI vs interfaces.
> I've been all for MI up to the moment where Marcus Boerger came up with
> this:

>> class Document implements Printable {
>>   delegate Printable $print;
>>
>>   function __construct() {
>>     $this->print = new PrintHandler($this);
>>   }

> This combines the pros of MI with the advantages of "favour composition
> over inheritance". I took this snippet an posted is an argument against
> MI on our team's private newsgroup server. Then there was a reaction
> that left me baffled:

>> MI in PHP? Sure, they have to. MI being polarising is no reason that
>> it shouldn't be implemented. MI can be very handy and it belongs in
>> a language used by people that want quick solutions. People being
>> all against it for academic or paedagogic reasons have simply
>> chosen the wrong battleground for their disussions.

> This is a valid argument. PHP has always been the BORG language that
> assimilates every positive aspect of other languages. Nowadays PHP users
> can use complex class hierarchies, interfaces, expections ans a lot
> more. But they may still use simple functions and use "global" for their
> variables.

> So why not? Give the "users" namespaces and hide them if they don't use
> them (global namespace for all existing code). Give them multiple
> inheritance but retain the interfaces. And first of all, implement
> Marcus Boergers suggestion for native "delegates". *g*