54_traits_properties.php

<?php

trait one {
  public $prop;

  protected function someMethod()
  {
    // do something hidden from the
    // outside world
  }
}

class two {
  use one;

  public $prop; // "E_STRICT: This might be incompatible..."

  public function someMethod() // But this is completely OK
  {
    // do something publicly
  }
}

// WHY ?

54_traits_with_exceptions_off.php

<?php

error_reporting(0);

trait one
{
    /** prop1 */
    protected $prop = 0;

    /** method1 */
    public function method() {}
}

class two
{
    use one;

    /** prop2 */
    protected $prop = 0;

    /** method2 */
    public function method() {}
}

$two = new two();
$refl = new \ReflectionObject($two);

echo $refl->getProperty('prop')->getDocComment() . "\n";
echo $refl->getMethod('method')->getDocComment() . "\n";

#
#  Will output:
#
#  /** prop1 */
#  /** method2 */
#

// WHY ?

its following standard inheritance rules in this case ..

@lsmith77 it's not. I can easily override property with the same signature (publics/protected) in child class.

I tend to agree with @lsmith77, your annotation use-case seems weak to me (no offense). Properties from traits shouldn't be accessed by the class. Use the methods for that.

@marijn seems you don't understand what traits are in php (no offense). Traits are interpret-level copy-paste. There's just no way you can access properties from traits in the class, because there's simply no such thing as trait during runtime. Everything from the trait, including methods and properties is copied into final class before running your script (you can use reflection to check that). Methods are copied, properties are copied, both with their doc blocks. Every single part of the trait becomes rightful part of your class right immediately after you add use ... keyword into this class.

Problem is that in one case (methods) conflicts are ignored silently (if method's already defined in the class, even with different access level, - it's not copied from trait at all, no conflict raised) and in another (if property is already defined in the class, even with same access level and default value) - it causes E_STRICT exception. That's it. Annotations are just one example where this inconsistency becomes obvious.

Ok, thanks for clearing that up @everzet. However, I still think that it doesn't make any sense to "change" the value of property (which might not have been anticipated by the trait author) or overwrite a docblock from the class that is using the trait. What would be the use case for changing a properties value? I think that problem is prevented all together when properties are initialized in the constructor, opposed to in the property declaration (though I'm fuzzy at the moment how that would work in a trait). When it comes to method "changing" in the class that uses a trait, that is just plain wrong. This might cause completely erratic behavior because the method might not be functioning anymore as intended. This would be especially harmfull when that method is used by another method defined in the trait.

It's too bad that the error handling is so inconsistent though.

@marijn again, i'm not talking about overriding default values or access level, i'm talking about inconsistency like that:

<?php

error_reporting(0);

trait one
{
    /** prop1 */
    protected $prop = 0;

    /** method1 */
    public function method() {}
}

class two
{
    use one;

    /** prop2 */
    protected $prop = 0;

    /** method2 */
    public function method() {}
}

$two = new two();
$refl = new \ReflectionObject($two);

echo $refl->getProperty('prop')->getDocComment() . "\n";
echo $refl->getMethod('method')->getDocComment() . "\n";

will output:

/** prop1 */
/** method2 */