Re: [RFC][Discussion] Parser extension API
| From: | Benjamin Eberlei | Date: | Tue, 17 Feb 2015 12:29:58 +0000 |
| Subject: | Re: [RFC][Discussion] Parser extension API | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-82951@lists.php.net to get a copy of this message | ||
On Tue, Feb 17, 2015 at 1:22 PM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:
>
> 2015-02-17 15:09 GMT+03:00 Benjamin Eberlei <kontakt@beberlei.de>:
>
>> The visitor API is the essential part here and you left it out.
>
>
> Yes, I decided not to put Visitor in the RFC (this was added as open
> question to the RFC). But this part can be discussed in the case of general
> acceptance.
>
>
> 2015-02-17 15:09 GMT+03:00 Benjamin Eberlei <kontakt@beberlei.de>:
>
>> How does this work with Engine Extensions, are they considered for all
>> require/include's *after* the registrtion? How does this work with opcache?
>
>
> Yes, parser extensions will be called for all require/include/evals after
> registration. This part is transparent for opcache, because opcache just
> stores an opcodes for the file. AST is parsed only once for each file, then
> hooks can transform the AST and after that compiler will produce a final
> opcodes that can be stored for that file in the opcache. So, I expect no
> impact on opcache logic.
>
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.