Hi Stan,
I see this in a much simpler fashion. Treat traits as a preprocessor
step semantically.
Internally, trait methods on multiple classes may point to the same
method to save resources, but in my opinion there's no need to
complicate matter by introducing new resolution rules, scopes, and
so on.
The way I see it:
1) Property/Method name conflicts on trait/class, within the class
including the trait raises Fatal Error.
Well, with methods this is ok, but properties are not Java fields
which are known at compile time, so it is not that easy. Even when
they are known beforehand things are more complicated.
State is usually even less composable than behavior/methods.
3) There's a single space for a class property and its trait
properties, so access works as if it was all class properties.
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
Feedback?
Regards,
Stan Vassilev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Stefan Marr
Programming Technology Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://prog.vub.ac.be/~smarr
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
