Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82965
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
Message-ID: <54E3553E.6080608@gmail.com>
Date: Tue, 17 Feb 2015 14:50:38 +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: PHP internals list <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>	<54E3439D.30407@gmail.com> <CAEbg-4bWaYg1bwDEfG2Rh_w9XyVrqT9vxyuW7cnCtX04Wjf2jw@mail.gmail.com>
In-Reply-To: <CAEbg-4bWaYg1bwDEfG2Rh_w9XyVrqT9vxyuW7cnCtX04Wjf2jw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020103090902070100010407"
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: rowan.collins@gmail.com (Rowan Collins)

--------------020103090902070100010407
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Alexander Lisachenko wrote on 17/02/2015 14:21:
> 2015-02-17 16:35 GMT+03:00 Rowan Collins <rowan.collins@gmail.com 
> <mailto:rowan.collins@gmail.com>>:
>
>     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);
>
>
> Ouch ) Don't like this way at all, because extensions should process 
> all files, even if it's not marked with some hints. What I want to see 
> is PHP analog of Java bytecode compilers, they can transform an 
> original source code into specific tokens and provide custom 
> extensions on top of that. So, I want to choose between php.ini option 
> and explicit methods. Let's see another opinions.

It's interesting that you used the word "extension" there. If the hook 
can only be registered for in php.ini (and it would need to be 
PHP_INI_SYSTEM if you want to avoid OpCache needing to vary its cache on 
different settings) then these are basically extensions which happen to 
be written in PHP - you install them globally, they execute 
unconditionally, and they do things which can't be done any other way.

In that case, it would maybe make more sense to make this part of the 
"simplified extension API" discussed in a previous thread, rather than 
exposing it to userland at all. The only abilities you'd lose are ones 
which should never be used anyway, e.g. statically registering an 
extension, then dynamically changing its behaviour at runtime by 
altering global/static variables.

I think the same argument applies to per-file pragmas over per-install 
settings, as to Dependency Injection over global state - you should be 
able to reason about each module of code in isolation, reuse it in 
different combinations, etc, etc. What if you want to use two different 
DbC extensions on the same server, and they collide with each other? 
What would the error look like if you failed to install an extension 
that was required to process your source code as intended? A declare 
line (or Perl's use, or Python's import) gives a clear point where that 
requirement is defined.

Regards,
-- 
Rowan Collins
[IMSoP]

--------------020103090902070100010407--