Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82953
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEbg-4bRKdhUtHVOQrRdtpv312gMKyHGw98Hfh1yHCo+7mw9XA@mail.gmail.com>
References: <CAEbg-4aZytKiqG3Y5U-HrBMp2+JuGHu3UTOMLWiiUQn59FtpLw@mail.gmail.com>
	<CAEPJdukpp1JVGi+y_MPYhNro3uqmkTwTtErd4YUi57+AkNK66A@mail.gmail.com>
	<CAEbg-4bRKdhUtHVOQrRdtpv312gMKyHGw98Hfh1yHCo+7mw9XA@mail.gmail.com>
Date: Tue, 17 Feb 2015 12:48:42 +0000
Message-ID: <CAPwsocHiw8HahNsMmcnovd9EdfR5yZzroQcrMLAHd=5v1WY3iQ@mail.gmail.com>
To: Alexander Lisachenko <lisachenko.it@gmail.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: leight@gmail.com (Leigh)

On 17 February 2015 at 12:22, Alexander Lisachenko
<lisachenko.it@gmail.com> wrote:
> 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.

So: Internal Parse AST -> Extension Parse AST -> Generate OpCodes -> OpCache?

So if the parser extension does anything dynamic, then OpCache will
have the wrong version cached.