http://wiki.php.net/rfc/traitsmodifications
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like 'final'
could also do something special.
André had the same kinds of feelings. I feel marking 'non-final' would
be better, and suggest using 'default' for this purpose. See my earlier
email for more details and reasoning.
b) Support for 'non-breakable traits'
- Add trait-local scope
Really like the idea and how this could make traits less fragile.
e.g.
trait Foo {
trait $bar;
public $bar;
}
Could change the syntax to:
trait Foo {
var $bar = 'visibleByTrait'; // variable private to the trait --
zend_mangle_property_name('#Foo {NULL} bar')
public $bar = 'visibleByClass'; // variable public to the class it gets
composed in
}
class Test {
use Foo;
}
$t = new Test;
echo $t->bar; // 'visibleByClass'
Seems like it could allow traits to have their own independent state
(private properties), internally ~ zend_mangle_property_name('#' trait name
{NULL} prop name).
Small note: is there a plan to drop the T_VAR token?
Any objections, concerns, more thoughts on the concept?
I think it needs to work for methods as well as properties, so think the
'trait' keyword is better than the 'var' keyword for that reason. It
would seem strange prefixing a method with 'var'.
c) Extend 'use' syntax
Didn't quite understand, will read again.
Have you thought about how this could affect the reflection api and
documentation?
Yes, I had thought about it a bit. Now I've thought a bit further.
When extended syntax is just moving class and trait methods around
(essentially either duplicating them or omitting them), the reflection
API should just work on the results of that movement. I presume that is
what happens with traits.
When extended syntax is generating forwarding functions, I expect the
reflection API to return details of those forwarding functions. It can't
do anything else, as due to PHP's dynamic nature, the functions being
forwarded to are not immutable. I would document it as a forwarding
function generation mechanism, too, so confusion is avoided.
Having thought about it a bit further now, though, the reflection API is
arguably a bit useless in this case. Perhaps to mitigate this, a new
method could be added to ReflectionMethod to find details of the target
of a forwarding method for a particular object (at the particular time
the method is invoked).
Ben.