I like it,
additionally if you want to prevent conflicts from the start you can always go and define prefixed property names like below and use a getter to access them conveniently. trait Foo { private $Foo_prop; public function getProp() { return $this->Foo_prop; } } I am really looking forward to traits in 5.4! greetings, Benjamin On Thu, 16 Dec 2010 16:25:42 +0100, Stefan Marr <p...@stefan-marr.de> wrote: > Hi: > > From my point of view the right thing to do with regard to properties is > defined in the test cases below. > > The rational behind providing this semantics is based on the fact that PHP > allows to define properties dynamically anyway, so there is no way around > properties. > However, there should be a way that a developer can notice that the code > might not behave as expected in the composed class. > > It is true that behavior needs state to operate on, however, accessors are > a common pattern and fully supported by traits. Furthermore, traits are not > supposed to replace classes, and when a trait does more than just providing > code that is to be easily reused, then the designed should ask the question > whether that is not actually a class, which then provides the necessary > guarantees to enforce the invariances the code expects. > > Thus, I would like to keep traits as a lightweight concept for code reuse. > > Best regards > Stefan > > --TEST-- > Conflicting properties should result in a notice. > Property use is discorage for traits that are supposed to enable > maintainable > code reuse. Accessor methods are the language supported idiom for this. > --FILE-- > <?php > error_reporting(E_ALL); > > trait THello1 { > public $foo; > } > > trait THello2 { > private $foo; > } > > class TraitsTest { > use THello1; > use THello2; > } > > var_dump(property_exists('TraitsTest', 'foo')); > ?> > --EXPECTF-- > Notice: Trait THello1 and THello2 define the same property in the > composition of TraitsTest. This might be incompatible, to improve > maintainability consider using accessor methods instead. Class was composed > in %s on line %d. > > bool(true) > > > > > --TEST-- > Non-conflicting properties should work just fine. > --FILE-- > <?php > error_reporting(E_ALL); > > trait THello1 { > public $hello = "hello"; > } > > trait THello2 { > private $world = "World!"; > } > > class TraitsTest { > use THello1; > use THello2; > function test() { > echo $this->hello . ' ' . $this->world; > } > } > > var_dump(property_exists('TraitsTest', 'hello')); > var_dump(property_exists('TraitsTest', 'world')); > > $t = new TraitsTest; > $t->test(); > ?> > --EXPECTF-- > bool(true) > bool(true) > > hello World! > > > --TEST-- > Conflicting properties with different visibility modifiers should be merged > to the most restrictive modifier. > --FILE-- > <?php > error_reporting(E_ALL); > > trait THello1 { > public $hello; > } > > trait THello2 { > private $hello; > } > > class TraitsTest { > use THello1; > use THello2; > } > > $t = new TraitsTest; > $t->hello = "foo"; > ?> > --EXPECTF-- > Fatal error: Cannot access private property TraitsTest::$foo in %s on line > %d > > On 11 Dec 2010, at 17:47, Stefan Marr 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 >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php