Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82958
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
Message-ID: <54E3439D.30407@gmail.com>
Date: Tue, 17 Feb 2015 13:35:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAEbg-4aZytKiqG3Y5U-HrBMp2+JuGHu3UTOMLWiiUQn59FtpLw@mail.gmail.com>	<CAEPJdukpp1JVGi+y_MPYhNro3uqmkTwTtErd4YUi57+AkNK66A@mail.gmail.com>	<CAEbg-4bRKdhUtHVOQrRdtpv312gMKyHGw98Hfh1yHCo+7mw9XA@mail.gmail.com>	<CAEPJdumds30VxAatiD6s1zG4fkL26z30c=2FStgdU2tHr6qOUA@mail.gmail.com> <CAEbg-4aRaWMy1c3uk_nTG+OxNWOH_6OTmPNv1gZMLLo57_VNwQ@mail.gmail.com>
In-Reply-To: <CAEbg-4aRaWMy1c3uk_nTG+OxNWOH_6OTmPNv1gZMLLo57_VNwQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: rowan.collins@gmail.com (Rowan Collins)

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]