I keep most of this to other but two comments:
On Fri, 2011-11-11 at 11:00 -0500, Rasmus Schultz wrote:
> Lastly, when you reflect on a trait, it comes back as an instance of
> ReflectionClass. As pointed out, traits are probably more similar to
> interfaces than they are to classes, and they definitely don't have
> properties, as are exposed by the ReflectionClass type.
1) Interface use ReflectionClass, too.
2) Traits may (for whatever reason) have properties
$ php -r 'trait T { public $p; } ReflectionClass::export("T");'
Trait [ <user> trait T ] {
[...]
- Properties [1] {
Property [ <default> public $p ]
}
In general: Reflection is always quite close to the internal structures
not far abstracted away. Always closer to the C implementation than PHP
land. Changing that would affect multiple areas in there. This might
have benefits here and there but now it resembles the actual workings
better which has also some benefits ...
> I would also point out that the examples in the documentation (which
> it
> seems were just copied from the RFC?) do not demonstrate any real
> purpose
> of this feature. Is this the most anybody has attempted to do with
> this
> feature? Trying to come up with a real example, I didn't get very far
> before running into these stumbling blocks.
I once stumbled over
http://knplabs.com/blog/csi/php-materialized-path-tree
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
