Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 85.214.94.56 as permitted sender)
Date: Tue, 25 Nov 2008 13:39:50 +0100
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <557209447.20081125133950@marcus-boerger.de>
To: Christopher Vogt <christopher.vogt@rwth-aachen.de>
CC: Marcus Boerger <helly@php.net>, Stefan Marr <php@stefan-marr.de>, 
	<internals@lists.php.net>
In-Reply-To: <492B62A1.2000207@rwth-aachen.de>
References: <002b01c92d67$ae92fdc0$0bb8f940$@de> <79.C8.07308.CDE4C194@pb1.pair.com> <49203DF2.1020006@stefan-marr.de> <45289205.20081125005213@marcus-boerger.de> <492B62A1.2000207@rwth-aachen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Grafts, Traits, horizontal reuse
From: helly@php.net (Marcus Boerger)

Hello Christopher,

Tuesday, November 25, 2008, 3:27:45 AM, you wrote:

> Hej Marcus,

> I like your approach. It is clear and simple. It would probably solve
> 90% of the cases, where delegation is needed.

> I want to add that a manually defined method should automatically
> overwrite a delegated method of the same name.

> But I also want to bring up two reasonable situations your approach does
> not cover. Your approach does not allow to delegate only a selection of
> methods. This makes sense in order to limit the delegation to known
> functionality. To stick to your example, without selective delegation,
> new methods added to Counter would be automatically delegated to
> CounterUser. This might break things.

> A second situation not covered by your approach is renaming of delegated
> methods. This can be desirable due to name clashes or name changes for
> better understandability.

> Of course there is always the fall back to manually implementing
> delegation. And your approach alone would already be quite useful
> syntactic sugar. But additional syntactic sugar for the two situations
> described above would still be nice :).

> Another thing. I am not sure if you intended that, but I think
> delegation should not force using an Interface definition. Interfaces
> are helpful in combination with type hinting, but for people who prefer
> duck typing, it is reasonable to not explicitly define them. Let's leave
> this choice to the people :).

Your points are all well observed. And yes I limit what my approach can
do in order to Keep It Simple Safe (KISS). While still being able to
manually interfere with/overload the autogenerated code when necessary.
At the same time forcing to delegate to a defined Interface and not
allowing to rename on the fly prevents abusing the functionality and
helps maintainability. On the other hand it forces you to think before
coding as this approach comes with a lack of functionality.

Maybe in a second step we could make the defined interface optional but
with my implementation in mind that might not be the easiest thing to do.

> Best regards

> Christopher




Best regards,
 Marcus