Alexander Lisachenko wrote on 17/02/2015 12:41:
2015-02-17 15:29 GMT+03:00 Benjamin Eberlei <kont...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
