Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51057
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 178.77.98.152 cause and error)
To: Stefan Marr <php@stefan-marr.de>
MIME-Version: 1.0
Date: Thu, 16 Dec 2010 17:01:03 +0100
Cc: "internals@lists.php.net Development" <internals@lists.php.net>
In-Reply-To: <581ACCE6-71A4-444F-A226-8D87E1B43EEF@stefan-marr.de>
References: <89C52156-CF92-4DDB-8BA4-4ABF6883512C@stefan-marr.de> <581ACCE6-71A4-444F-A226-8D87E1B43EEF@stefan-marr.de>
Message-ID: <8e4cc08313fd6b9b9df09ab4e5f1d66e@beberlei.de>
User-Agent: RoundCube Webmail/0.3.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Traits and Properties
From: kontakt@beberlei.de (Benjamin Eberlei)

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 <php@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