2015-02-17 16:35 GMT+03:00 Rowan Collins <rowan.coll...@gmail.com>: > I think "should" is OK for extensions, but not for userland hooks. There > needs to be a very firm definition of the right and wrong way to implement > these hooks, which can at the very least warn the user when they are > slipping into undefined behaviour.
Thanks for this point. Added this question to the list of open issues in RFC. My vision is to update a documentation with clear description, why parser extensions should be registered statically without conditions. Parsing process and limitations should be also described in the RFC. 2015-02-17 16:35 GMT+03:00 Rowan Collins <rowan.coll...@gmail.com>: > The other alternative is to go to the other extreme, and have the > extensions scoped to a particular file, more like Perl pragmas. Dare I say > we could use the declare() syntax that everyone seems to have an irrational > hatred of? > > declare(pragma=Example\DbcParserExtension); > Ouch ) Don't like this way at all, because extensions should process all files, even if it's not marked with some hints. What I want to see is PHP analog of Java bytecode compilers, they can transform an original source code into specific tokens and provide custom extensions on top of that. So, I want to choose between php.ini option and explicit methods. Let's see another opinions. Thanks!
