trait Counter {
var $value;
public function inc() { $this->value++; }
...
}
trait Color {
var $hue;
var $saturation;
var $value;
public function getRGB() { /* ... */}
...
}
class MyClass {
use Counter, Color;
}
Ok, you could argue that you than will have to refactor your property
names in your state. But then you will break other traits. Even worth,
this trait is defined in a widely used framework and your breaking other
peoples code just by changing implementation details which should not
even be visible to your users.
I do not think that this simple model is practicable. Unfortunately, it
is implied by the current state-less proposal, if we do not forbid any
access to properties inside of trait methods (which sounds like a stupid
idea to me). :(
Regards
Stefan
Hi,
Since the expectancy of a trait is it'll be used in many other classes
horizontally, I wouldn't think people will start taking generic names in
traits as they do in normal classes.
I'd personally expect this naming convention more likely:
trait Counter { protected $counterValue; }
trait Observable { protected $observableListeners; }
And so on. The benefit is it's easy to implement, understand, and use.
However if this is not acceptable to many, and we could live with the
complication of it, the best idea for trait property access I suppose would
be this:
trait Observable {
protected $listeners;
}
class Any {
use Observable;
function accessTraitProperty() {
var_dump($this->Observable->listeners);
}
}
Hence namespacing trait state into an automatically created object of the
same name, and we're done.
On the other said, a all traits could have an automatic property "owner",
which gives it access to the class state/properties.
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
