Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:51090 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45674 invoked from network); 19 Dec 2010 16:22:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Dec 2010 16:22:39 -0000 X-Host-Fingerprint: 65.19.76.48 unknown Date: Sun, 19 Dec 2010 11:22:38 -0500 Received: from [65.19.76.48] ([65.19.76.48:14480] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 73/1D-35939-D413E0D4 for ; Sun, 19 Dec 2010 11:22:38 -0500 Message-ID: <73.1D.35939.D413E0D4@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> 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-18, Stefan Marr wrote: > On 16 Dec 2010, at 23:31, Larry Garfield wrote: > > - When the visibility collides, should we be folding to the most > > restrictive or least restrictive? I'm not sure myself; I'm more > > interested in your reasoning for going for most-restrictive. > So, in general, I think, there is no 'right thing' to do here, because > the definitions seem to be incompatible but that is only decidable at > the application-level. > > There is another, related, edge-case in the test case below. In the > test we have different initial values for the properties, which makes > it 'obvious' that they are incompatible. Thus, in that case I would > argue for a E_COMPILE_ERROR instead of a notice. > > The reason to use the stricter modifier is, well, arbitrary. > > At least I do not find an argument for either way that completely > convinces me. At the moment, the main reason is that 'public' can be > considered to be the default visibility modifier. Based on the > semantics of 'var' and dynamic properties. Thus, private tends to > imply that an additional constraint was consciously applied to the > property, which should be preserved. I'd argue that traits should follow similar rules to normal class inheritance. In that paradigm, you can override a previously defined member by using equal or _greater_ visibility only -- i.e., you can't make it _less_ visible (e.g., making a property declared as protected in the parent class private in the extending class). With traits, it seems like we should go with whatever is _most_ visible, as then no matter what traits are mixed in, access is guaranteed. > Well, but as I said, thats kind of arbitrary and if you look at the > inheritance rules and try to reason from the view of clients with > respect to the external interface, then going with public as the > chosen modifier also starts to sound reasonable... 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). -- 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