Include this extension in the PHP core and provide a hook API

[lisachenko]

I want to suggest to include this extension into the core to provide an API for miscellaneous userland extensions. Main idea is to give a userland code control over the produced source-code.

Chain is following: Source Code => Tokenizer => AST => Engine hooks+PHP userland hooks => Compiler => Opcodes => Execution

Why it can be a great thing: native source-code AST (static analyzers, code beautifiers), language extensions (AOP, DbC, SQL-like native syntax).

This requires to create an userland-function, probably, register_parser_extension(ParserExtensionInterface $extension) that will add an extension as parser hook.

Next additional thing is ParserExtensionInterface interface with process(Node $node) method that will receive ast\Node class and should return a modified node or tree.

Each registered extension will be called consequently, allowing to transform the source code. Last result will be used by compiler to generate final version of opcodes.

[lisachenko]

Ping, @nikic ) Can we bump this thread to move this beautiful gem into the PHP7.1?

[nikic]

@lisachenko It's still a bit early for PHP 7.1 (we haven't even branched yet), I'd wait until PHP 7 is out :)

[lisachenko]

@nikic oh, it's ok ) Just want to see, that this topic is still interesting for you and php-AST can be moved to the PHP core in future versions.

[sebastianbergmann]

I, too, would love to see this bundled with and enabled by default for PHP 7.1.

[GrahamCampbell]

👍

[JoyceBabu]

👍

[lisachenko]

For anyone who wants this in the PHP core, here is a link to the draft version of RFC: https://wiki.php.net/rfc/parser-extension-api

[funivan]

👍

[JoyceBabu]

@lisachenko When Opcode caching is enabled, how will the hook API work? The same PHP file could be parsed into different Opcodes based on the bound transform functions.

[lisachenko]

@JoyceBabu parsing, as well as possible hooks will be called only once with enabled opcode caching. There won't be any calls to the hooks, because source code AST will be transformed into an opcodes and cached by the engine.

[JoyceBabu]

That is going to cause a lot of confusion to several users. Because any time varying or indeterministic code in the callback will retain the value of the first invocation.

But since this will be used mainly by advanced PHP users, proper documentation will reduce the confusion.

PS: This will be very useful when writing Templating Engines.

[lisachenko]

PHP with enabled opcode caching working in the same way for production mode. All files are served directly from the memory, no file checks at all, if you want to upload a new version of file (for example, symfony container with new host names, passwords, etc) then you should call opcache_invalidate() function to keep opcodes in sync with original source code.

Hook is just additional logic to transform the AST source, nothing more. What is more important: how to register that hooks, because there will be time, when several core files are loaded (without enabled hook), then hook will be registered and only after that all next files will be analysed/transformed.

I can see two ways:

• put a class names into the php.ini, so they will be loaded by PHP immediately at the beginning of request
• leave as-is, like with register_shutdown_function, register_exception_handler, etc - it's ok that some files won't be processed during the initialization of framework/application source code.

[msjyoo]

+1

[jansor]

+1

[jeremeamia]

👍