On Mon, 2012-01-30 at 11:48 +1000, Ryan McCue wrote: > Johannes Schlüter wrote: > > PS. Mind that the example you've given even works on files not included > > by parsing files, whereas internal reflection provides information what > > actually is available from engine point of view ... > > The original reason I wrote that class was for a documentation tool, so > that we could discover classes before loading the files.
Right, I can see the need. But I think it is a different project from the simple "ReflectionFile" thing, as long as that is supposed to work with the current reflection system. Doing a "static reflection" from inside PHP is not easy as currently the parser is bound quite tight to the engine and our compiler, directly affecting function and class tables. We'd have to split that out and even if we do that there's one benefit(*) when doing it in PHP userland: It will always be bound to valid syntax for the given PHP interpreter. It won't work cross-version when we change the language. (so running 5.3 you couldn't analyze 5.4 code which might use traits etc.) a userland implementation can be made version independent and updated with support for new versions without breaking support for the old version. Of course doing this in userland means cost of performance, but I expect that IO on the one side and client code using the analyzed data on the other side have a bigger impact and the difference can almost be neglected, but that's a guess. As a remark, there's another static reflection project: https://github.com/manuelpichler/staticReflection maybe you can work together? To create the best :-) johannes *) of course there are all those other benefits of writing userland code like being simpler for the user to understand and debug, being simpler to maintain, which means more potential contributors, ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
