Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35805 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16292 invoked by uid 1010); 26 Feb 2008 00:13:31 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 16277 invoked from network); 26 Feb 2008 00:13:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2008 00:13:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=dz@bitxtender.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=dz@bitxtender.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error) X-PHP-List-Original-Sender: dz@bitxtender.com X-Host-Fingerprint: 80.237.132.12 wp005.webpack.hosteurope.de Received: from [80.237.132.12] ([80.237.132.12:59581] helo=wp005.webpack.hosteurope.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D6/7E-29498-8A953C74 for ; Mon, 25 Feb 2008 19:13:30 -0500 Received: from dslb-084-056-012-061.pools.arcor-ip.net ([84.56.12.61] helo=[192.168.0.102]); authenticated by wp005.webpack.hosteurope.de running ExIM using esmtpsa (TLSv1:RC4-SHA:128) id 1JTnRk-00005e-OI; Tue, 26 Feb 2008 01:13:25 +0100 Cc: internals Mailing List , Marcus Boerger Message-ID: <64F9EBD2-7612-42D0-BD29-7F80A7DB0A63@bitxtender.com> To: php@stefan-marr.de In-Reply-To: <47C317F4.2080301@stefan-marr.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 26 Feb 2008 01:13:23 +0100 References: <47C317F4.2080301@stefan-marr.de> X-Mailer: Apple Mail (2.919.2) X-bounce-key: webpack.hosteurope.de;dz@bitxtender.com;1203984810;7caa5be5; Subject: Re: [PHP-DEV] How to build a real Trait thing without exclusion and renaming From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=) Am 25.02.2008 um 20:33 schrieb Stefan Marr: > Hi, > > there is a lot of discussion going on about how traits should actually > work in PHP. > > Currently, one of the main challenges seams to be to agree on a > suitable > mechanism to avoid breaking traits and there behavior. > Eventually, there seams to be a large discomfiture on the excluding > of methods and the interweaving of methods from different traits. > > I can agree on the opinion, that a unconditional exclude mechanism > could accidentally break traits. > But, I really do like the notion to be able to interweave traits and > compose something new from it, which results in an overlapping > construct using the appropriate methods for a concrete problem. > Well, this implies traits are not units of black-boxed reuse. They > do act really fine-grained and will require the knowledge about the > used methods. Yes. This is how I understood them. I really don't think we need all this complicated stuff for potential what-if situations that arise from people not understanding how to use Traits. You are completely right that Traits should not be regarded as black boxes. I think I said it in an earlier mail - this entire discussion about conflict resolving with aliasing etc is pretty void because it's always assumed that Traits change, or developers using them don't (want to?) know the inner workings. Traits are mixed into classes statically, using an explicit syntactical facility. That means we can assume the developer in question knows what he is doing. That also means we can expect him to check for potential conflicts/breakage and resolve it up front, as you're suggesting further down in your mail. > Therefore, remove/exclude is bad, we need to get rid of it. > There are some thoughts about aliasing. It seams to be not the > natural/closest solution. Renaming semantics would be more natural, > but it implies an exclude of the old method, too. Thus, renaming > could accidentally breaking a trait. Eventually, renaming needs to > be avoided, too. > > Ok, lets get a step back and recall what traits have to achieve. > > Traits try to be a construct to allow the reuse of a group of > semantical related methods. > They do not try to replace inheritance or the delegation patter. > They are still valid means to reuse "complex behavior and state" > things. > Instead, the way to go with traits should be to reuse a small, > predominantly independent (but semantically related) number of > methods not justifying to build a full fledged class from them. Use > traits to build a class from them, which adds some additional > semantics/behavior to the set of methods got from the traits and > build a complete blue print for objects from it. > > The main thing here seams to be that the current proposal does not > fulfill the claim to combine the traits properly in the case of > conflicts. Instead, there is a lot of potential to break the traits > behavior. > > Let's try to find a notation where the traits are combined and > conflicts are solved upfront, before being applied to the class. > (This is even the way the implementation works right now.) Winner. +1. > To get rid of exclude and rename I would like to propose the > following: > > //Example from the RFC with the cross-over conflict to be solved > trait A { > public function smallTalk() { > echo 'a'; > } > public function bigTalk() { > echo 'A'; > } > } > > trait B { > public function smallTalk() { > echo 'b'; > } > public function bigTalk() { > echo 'B'; > } > } > > //here the new notion of combing traits and resolving conflicts > upfront > class Talker { > use A, B { > B::smallTalk instead A::smallTalk; > A::bigTalk instead B::bigTalk; > A::bigTalk as talk; > } > } > > > The new ``use`` is defined as use with a list of traits to be > included into the class. > Since the exclude is not appropriated, conflicts could be solved a > lot more explicitly with the new ``instead`` keyword. > It has be read as: use B::smallTalk instead of A::smallTalk, which > solves the conflict explicitly and avoids the need for an exclude > operator with the power to exclude arbitrary methods. > If more traits are combined it could look like ``A:foo instead > B::foo, C::foo;`` How about "B::smallTalk supersedes/replaces A::smallTalk" ? David