Re: [RFC][Discussion] Parser extension API

Alexander Lisachenko wrote on 17/02/2015 12:41:

2015-02-17 15:29 GMT+03:00 Benjamin Eberlei <kontakt@beberlei.de>:

Well not really, depending on the path towards a require a parser extension is already registered or not. Or you have conditional registration of extensions. So you could load a file with an extension registered, but it still serves the old opcodes for that file.

Technically, this will be possible, however, Parser Extensions should be registered ASAP during bootstrap process, near spl_autoload_register(), stream_wrapper_register(), stream_filter_register(), etc..

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. Note that spl_autoload_register doesn't affect OpCache because it only changes the mapping of a class to a parsed file (keyed on the file system path to the source), not the compiled contents of that file. If AST hooks can be registered on a global scope at any time, then compiling the same file can lead to different op codes at different times (e.g. page loads which take a different path through the code), which would mean the OpCache would need extra information in its keys to cache each possible version.

One more possible way for this RFC is to remove these register/unregister methods from the Php\Parser\Engine class and add an option to the php.ini with list of classes to load. This option can be adjusted then per project/directory. Is this more suitable?

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); Regards, -- Rowan Collins [IMSoP]