Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51103 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14906 invoked from network); 20 Dec 2010 23:21:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Dec 2010 23:21:22 -0000 Authentication-Results: pb1.pair.com header.from=php@stefan-marr.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@stefan-marr.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 81.20.134.149 cause and error) X-PHP-List-Original-Sender: php@stefan-marr.de X-Host-Fingerprint: 81.20.134.149 vps-1012701-4512.united-hoster.de Received: from [81.20.134.149] ([81.20.134.149:56039] helo=vps-1012701-4512.united-hoster.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EC/98-59680-0F4EF0D4 for ; Mon, 20 Dec 2010 18:21:21 -0500 Received: from cust194-138.dsl.as47377.net ([62.166.194.138] helo=[192.168.0.26]) by vps-1012701-4512.united-hoster.de with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1PUp2Z-0007mm-4B; Tue, 21 Dec 2010 00:21:17 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii In-Reply-To: <4D0F7E99.8050705@garfieldtech.com> Date: Tue, 21 Dec 2010 00:21:08 +0100 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: <764A364B-173B-401B-83FA-A61D45BE99CB@stefan-marr.de> References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <201012132027.59678.larry@garfieldtech.com> <76C593EE-BCCA-4BBD-B625-B6AE9340B20C@stefan-marr.de> <73.1D.35939.D413E0D4@pb1.pair.com> <8F.32.11788.5FF5F0D4@pb1.pair.com> <4D0F7E99.8050705@garfieldtech.com> To: larry@garfieldtech.com X-Mailer: Apple Mail (2.1082) Subject: Re: [PHP-DEV] Traits and Properties From: php@stefan-marr.de (Stefan Marr) Hi Larry: On 20 Dec 2010, at 17:04, larry@garfieldtech.com wrote: > Perhaps if both traits use the same variable name, visibility, *and* = default value then there is no error? There is not fatal error, however, currently there is E_STRICT notice. > I suspect this issue dovetails with the Traits-and-interfaces thread = from earlier. Ehm, not sure what you want to get at. The idea of expressing that the composing class needs to satisfy an = interface, or perhaps inherit from a specific class still seems to have = a number of valid use cases. However, there was a single strong opinion against it, as far as I = remember. Anyway, on the topic of properties. For the records, I updated the RFC with the following section. http://wiki.php.net/rfc/horizontalreuse#handling_of_propertiesstate Comments are welcome. Thanks Stefan =3D=3D=3D=3D=3D Handling of Properties/State =3D=3D=3D=3D=3D Traits do not provide any provisioning for handling state. They are meant to provide a light-weight mechanism for flexible code = reuse, with the mean goal being to avoid code duplication. Moreover, should not be confused with typical use cases of classes. When a strong coherence/coupling between methods and state is required, and certain invariants have to be maintained on the state, this is a = good=20 indication that a class is the right abstraction to implement that = problem=20 with. However, every behavior needs state to operate on, otherwise it could be = just a static functional helper method. Thus, trait code will either need to use accessors, which is favorite = way to go since it provides full traits semantics, or they use properties, = which is possible but rather a convenience feature. Since state is a complex problem, and the knowledge about compatibility = of=20 state form different traits is only present in a concrete composition, = proper state handling would need language features which are currently = considered beyond the scope of what is necessary for PHP. (See = [[http://scg.unibe.ch/archive/papers/Berg07eStatefulTraits.pdf|Bergel et = al]]) Thus, the goal for a consistent language design is to raise awareness of = the problem, promote the use of accessors, and break early in case the = changes to a trait is potentially problematic for a class using it. This results in = the following rules: - Properties are considered incompatible if they differ in their = definition. This means, they differ in the applied modifiers (static, public,=20 protected, private) or their initial value. - Incompatible properties result in a fatal error. - In all other cases, i.e., when the definitions are identical, an = E_STRICT notice is shown to raise awareness about the potentially = problematic, and discouraged use of properties. - For those checks, all properties are treated equal. Properties from = the=20 base class and the composing class have to be compatible with = properties from traits as well as the properties between all traits have to be=20= compatible. - Non-coliding properties, and properties which are not considered=20 incompatible behave exactly the same as if they would have been = defined in the composing class. This property handling was implemented in = [[http://svn.php.net/viewvc?view=3Drevision&revision=3D306476|SVN = revision 306476]] and examples are given in the test cases. >=20 > --Larry Garfield >=20 > --=20 > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >=20 --=20 Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525