On Thu, Jul 31, 2014 at 9:03 PM, Andrea Faulds <a...@ajf.me> wrote: > On another note, while we *could* allow extensions to hook into the AST, > I’d stray away from letting them modify it and implement new features. That > really doesn’t sound like a good idea at all (I could elaborate on why, but > I won’t bother unless someone asks me).
Why do you think this isn't a good idea? I think it would be a nice way to prototype language features before pulling them into PHP. Though admittedly I don't think there are many things that could be implemented that way. > Letting them read it would clearly be a good thing though. Side note: > Would that obsolete your PHP-Parser userland library once an extension > allows reading the AST? If an extension is written, perhaps it should have > the same API as your library had. I believe many projects already use it. > A native extension has the limitation that it will not be able to parse files for newer PHP versions (which, depending on the use case may or may not be a problem) and probably won't provide a stable structure across versions. At least I think giving BC guarantees on the AST structure between minor versions would be way too limiting for us. As such I think both a native ext (which provides awesome perf) and PHP-Parser (which provides x-compat) have their place ;) > On an *implementation* note, I assume this is based on the existing > constant ASTs, unless you renamed it to something other then zend_ast. Does > this cause any problems for them? While I can see the benefits of course, > I’d just like to be sure that the validator doesn’t let anything slip > through. > Yes, the AST structure is based on the existing work on constant scalar expressions, though by now the structure and API deviate a good bit from that. It doesn't cause problems for them - constant expressions go through a validation that checks that only valid nodes are used and adjusts those nodes that have special representation for the constexpr case (e.g. constant and class constant access). Nikita
