On 2010-12-18, Stefan Marr <p...@stefan-marr.de> 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 | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
