Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54151
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain openmv.com from 64.15.152.204 cause and error)
To: "'Alex Howansky'" <alex.howansky@gmail.com>
Cc: <internals@lists.php.net>
References: <4E29949C.9020209@gmail.com> <004701cc4890$f9d63f80$ed82be80$@com> <4E29B780.1030009@gmail.com>
In-Reply-To: <4E29B780.1030009@gmail.com>
Date: Fri, 22 Jul 2011 14:41:44 -0400
Message-ID: <007901cc489f$01d02580$05707080$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcxIl3LJiJpqQb0WReOaFtRCiw1LQgAAYjUA
Content-Language: en-ca
Subject: RE: [PHP-DEV] 5.4a2 trait attribute name conflict resolution
From: jbondc@openmv.com ("Jonathan Bond-Caron")

On Fri Jul 22 01:46 PM, Alex Howansky wrote:
> 
> Sure, but in this case, I created the conflict intentionally because I
> *want* to override it, and I'm not allowed to like I am with methods.
> Don't you think that's inconsistent?
> 

Agree

>  > The short answer is it's not a bug but maybe an implementation  > 
> issue... should it be an E_WARNING instead of E_STRICT?
> 
> At least. Consider the situation where I'm using classes/traits from 
> somebody else's library that I may not be intimately familiar with.
> I'll have to know what every one of their properties is named so I can 
> plan my code accordingly -- else I'll silently start getting their 
> values in what I think are my variables.

Part of the problem is if you have something like:

 trait foo
 {
       private $zoo = 'important_do_not_modify';

       public function showZoo(){
         echo $this->zoo;
        }

       public function doSomething(){
         if($this->zoo !== 'important_do_not_modify') die('bad');
        }
 }

 class baz
 {
       use foo;
       private $zoo = 'modified';
}

 $obj = new baz();
 $obj->bar();
 echo $obj->showZoo(); // modified
 echo $obj->doSomething();

You can essentially 'break' the trait. So if you think of using someone
else's library/trait, it's not fun either when you break something without
knowing it.
But even then, I'm with you on allowing to change the default property value
in the composing class (I'm in favor of it).

What traits would likely need is:
trait foo
{
       trait $zoo = 'important_do_not_modify';

       public function doSomething(){
         if(trait::$zoo !== 'important_do_not_modify') die('bad');
        }
 }

So that traits can keep their own private state (Ben Schmidt's idea)