Hi! On 2 Aug 2014, at 21:44, Nikita Popov <nikita....@gmail.com> wrote:
> 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. If people can extend the syntax, they will, and I don’t like the possible consequences of that. I’m all for overloading, but if people start relying on custom syntactical features, it means non-portable and confusing to read code. Granted, it might be useful for prototyping, but prototyping itself would be easier with an AST, so I’m not sure it matters. > 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 ;) Yeah, I was thinking that you could keep it around for version compatibility. You could even make your library pass through to the native ext where possible. :) > 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) Ah, I see. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
