Re: Traits and Properties
| From: | Richard Quadling | Date: | Mon, 13 Dec 2010 13:13:22 +0000 |
| Subject: | Re: Traits and Properties | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-51018@lists.php.net to get a copy of this message | ||
On 11 December 2010 16:47, Stefan Marr <php@stefan-marr.de> wrote:
> Hi:
>
> Traits do not provide any special provisioning for handling properties, especially, there is no
> language solution for handling colliding property names.
> The current solution/idiom for handling state safely in a trait is to use either abstract
> set/get methods or an abstract get that returns a reference to the property in the class.
>
> However, at the moment it is possible to define properties in a trait:
>
> trait Foo {
> private $a;
> public $foo;
> }
>
> For the moment, that information is completely ignored, thus:
>
> class Bar {
> use Foo;
> }
> property_exists('Bar', 'a') === false
>
>
> Well, and that is a rather inconsistent status-quo.
>
> I would like to have that fixed in one or another way.
>
> One possibility would be to forbid property definition in a trait altogether.
> That reduces a bit the possibility to have wrong expectations about properties, however, the
> dynamic property creation is still possible.
>
> Another way would be to merge the properties in the composing class.
> The question here would be how to treat visibility modifiers: how to merge public and private,
> should it result in public, or private?
> And, to discorage users to go this way, should there be a STRICT notice? Options here are a
> notice whenever a property is defined in a trait, or whenever properties are silently merged.
>
>
> Comments very welcome.
>
> Thanks
> Stefan
From the rfc [1], "A Trait is similar to a class, but only intended to
group functionality".
I'm guessing that says it all. A trait has no properties.
But.
If properties are to be added to a trait, I think that should come as
a further enhancement and let traits start out as "methods only".
If a trait is properties, then also supporting constants and the other
sort of set/get properties would provide a strong level of
consistency. If I can put it in a class, I can put it in a trait.
As visibility on the traits methods can be manipulated via the
aliasing mechanism, so should any visibility to a property.
Richard.
[1] http://wiki.php.net/rfc/horizontalreuse
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY