Re: Traits and Properties
| From: | Matthew Weier O'Phinney | Date: | Sun, 19 Dec 2010 16:22:38 +0000 |
| Subject: | Re: Traits and Properties | ||
| References: | 1 2 3 4 5 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-51090@lists.php.net to get a copy of this message | ||
On 2010-12-18, Stefan Marr <php@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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc