Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51094 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25325 invoked from network); 20 Dec 2010 13:53:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Dec 2010 13:53:59 -0000 X-Host-Fingerprint: 65.19.76.48 unknown Date: Mon, 20 Dec 2010 08:53:58 -0500 Received: from [65.19.76.48] ([65.19.76.48:29112] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8F/32-11788-5FF5F0D4 for ; Mon, 20 Dec 2010 08:53:58 -0500 Message-ID: <8F.32.11788.5FF5F0D4@pb1.pair.com> To: internals@lists.php.net 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> User-Agent: slrn/pre1.0.0-18 (Linux) X-Posted-By: 65.19.76.48 Subject: Re: [PHP-DEV] Traits and Properties From: weierophinney@php.net (Matthew Weier O'Phinney) On 2010-12-19, Stefan Marr wrote: > On 19 Dec 2010, at 17:22, Matthew Weier O'Phinney wrote: > > Exactly. I wouldn't default to public on conflicts, though -- just with > > the highest declared visibility (e.g., if one trait defines as private > > and the other as protected, protected wins). > I am currently actually implementing the most restricted proposal: all > differences in the property definition will lead to a fatal error. > > The reasoning behind this is, that the semantics of state is not > predictable and all changes in the class/traits hierarchies which are > incompatible should give the developer an immediate feedback, i.e., > make potentially incompatible code break. That is not the most > 'dynamic' of all possible solutions but seems to fit with the rest of > PHP. That makes sense to me as well; having conflicting properties due to multiple traits implementing them is a good way to lead to inconsistency and difficult to test/predict code. > What I have in mind is also not how the methods integrate into the > inheritance chain, thus, a property in the body of the class does not > override all property definitions in traits (this is the case for > methods). I think that will be useful for the very same reason. And > well, I hope an educative error message will steer the crowed in the > right direction to use accessors. -- Matthew Weier O'Phinney Project Lead | matthew@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc