Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35718 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 47887 invoked by uid 1010); 22 Feb 2008 05:03:59 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 47869 invoked from network); 22 Feb 2008 05:03:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Feb 2008 05:03:59 -0000 X-Host-Fingerprint: 72.198.16.221 ip72-198-16-221.ok.ok.cox.net Received: from [72.198.16.221] ([72.198.16.221:14687] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 90/8A-64513-EB75EB74 for ; Fri, 22 Feb 2008 00:03:59 -0500 Message-ID: <90.8A.64513.EB75EB74@pb1.pair.com> To: internals@lists.php.net Date: Thu, 21 Feb 2008 23:03:58 -0600 User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 References: <001c01c87264$3c01b4e0$b4051ea0$@de> In-Reply-To: <001c01c87264$3c01b4e0$b4051ea0$@de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 080221-0, 02/21/2008), Outbound message X-Antivirus-Status: Clean X-Posted-By: 72.198.16.221 Subject: Re: RFC: Traits for PHP From: spam.goes.in.here@gmail.com (Joshua Thompson) php@stefan-marr.de wrote: > Hi, > > during last six months I've studied a language construct called Traits. > It is a construct to allow fine-grained code reuse and in my opinon > this would be a nice feature for PHP, which I did like to propose here. > The following RFC deals with the questions what Traits are, how they are > used, why they are usefull and how they do look like in PHP. > A patch implementing this new language construct is available, too. > > Thank you for your attention and I'm looking forward to hear your comments > :) > > Kind Regards > Stefan I came across one piece of information on aliasing that may not be obvious at first and therefore should probably be explicitly stated in the RFC and in the manual when this makes it into the core. Quoting : "Note that because the body of the aliased method is not changed in any way, so an alias to a recursive method is not recursive." This means that because there is no renaming of anything in the method body when aliased, a recursive call to the method in the trait does not make a recursive call in the aliased method. It will instead call the original method name, which could be the same body, a method defined in a different trait, or the method overridden by the client class. -- "Joshua Thompson"