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 <[email protected]>
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
