Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:35725 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44412 invoked by uid 1010); 22 Feb 2008 11:20:56 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 44397 invoked from network); 22 Feb 2008 11:20:56 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Feb 2008 11:20:56 -0000 Authentication-Results: pb1.pair.com smtp.mail=rquadling@googlemail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rquadling@googlemail.com; sender-id=pass; domainkeys=bad Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 64.233.184.228 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: rquadling@googlemail.com X-Host-Fingerprint: 64.233.184.228 wr-out-0506.google.com Linux 2.4/2.6 Received: from [64.233.184.228] ([64.233.184.228:34408] helo=wr-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 45/73-22931-610BEB74 for ; Fri, 22 Feb 2008 06:20:55 -0500 Received: by wr-out-0506.google.com with SMTP id c38so581910wra.17 for ; Fri, 22 Feb 2008 03:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=R5lLVGL+KcAVIWrguM5zMJml1qHreTuVmAbwdeoHGeM=; b=dLcVDQiT7t9aCc0ETFzS6STtadOtULwpxrvqY+U/OVdLvmF0fMI/96jhloDNnaCFCBDK/XGeOoSdvmgwp17vAW1f6ZAFBVURnGK9lsMwMvTcMp0elhXI8PNaoD3qtggA/v4yRnTKX/NIRq/Gid8cZ02RW4DaT8gymbiUylTurDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ec+lyWMXVm6rLJVGX3LJu7AWr7EW+vXzOJYghwS1eFB7KdeU3QwGugwy8oSX+aGu4w+EjIuN1Y8RFRvgFvhpX5We00uIyuo4594ObVMQWySlrcEdxBsvNdaq2UzDpmH6LTijguhF/3RnI4WQUn1rc7ASAHL2Tq9oak3wrOVkH8k= Received: by 10.115.90.1 with SMTP id s1mr5016908wal.41.1203679250748; Fri, 22 Feb 2008 03:20:50 -0800 (PST) Received: by 10.114.209.15 with HTTP; Fri, 22 Feb 2008 03:20:50 -0800 (PST) Message-ID: <10845a340802220320u74927492x54753bd1b7bda7ff@mail.gmail.com> Date: Fri, 22 Feb 2008 11:20:50 +0000 Reply-To: RQuadling@GoogleMail.com To: php@stefan-marr.de Cc: "Andi Gutmans" , "Internals Mailing List" In-Reply-To: <47BDFED6.4030303@stefan-marr.de> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001c01c87264$3c01b4e0$b4051ea0$@de> <698DE66518E7CA45812BD18E807866CE014A8D9D@us-ex1.zend.net> <47BDFED6.4030303@stefan-marr.de> Subject: Re: [PHP-DEV] RFC: Traits for PHP - Stateful Traits From: rquadling@googlemail.com ("Richard Quadling") On 21/02/2008, Stefan Marr wrote: > Hi, > > Andi Gutmans schrieb: > > a) > > I think Traits should be able to act as a self-contained behavior which can > > always be expected to work. For example if I want a Counter behavior > I would like > > that not to depend on the properties in the containing class. While I > don't > > think we should enable public nor protected properties in Traits I think > > allowing for private properties in Traits would come in very handy. > It also > > is no problem when it comes to mangling as we can use the Trait name. > > > > class Trait { > > private $counter = 0; > > function getNextSerialNumber() { > > return $this->counter++; > > } > > } > > > > I strongly recommend not to support protected/public and not to even get into > > the discussion of dealing with conflicts of such properties. > > But I think private is very useful. > Hope I got it right, since your example is a class? > > Ok, stateful traits are useful in the sense of having self-contained > units of reuse. Personally, I prefer them over stateless traits. > But, here we will get additional confusion. > > You don't like to handle with visibilities of properties? Fine :) > One way to do stateful traits is described in > http://www.iam.unibe.ch/~scg/Archive/Papers/Berg07eStatefulTraits.pdf > > But the way you have proposed is stricter and may be sufficient. > > To avoid confusion and misconception I would like to change your > proposal a bit. Private does suggest a semantics like methods, and would > require to apply the flattening on properties like on methods. Since we > do not like to handle conflicts, this would have to be done a bit > different, in my opinion. > > Let's change ``private`` to ``local``: > trait TCounter { > local $counter = 0; > function getNextSerialNumber() { > return $this->counter++; > } > } > > class Website { > use TCounter; > } > > The resulting composition would have a property resulting from the > TCounter property, but is only accessible from a method of the specific > trait, i.e., it is composition local. > > Just an additional though :) > > Kind Regards > Stefan I think I see an issue with including properties. If a trait is partially included at different levels of a layered object base uses 2 methods of a trait. extended uses 2 more methods of the same trait another_base uses 1 method of the trait. another_extended_base uses the remaining methods of the trait. You would need to control the inclusion of the properties. -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"