Re: Traits and Properties

From: 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

« previous php.internals (#51018) next »