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)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
