Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107728
To: PHP internals <internals@lists.php.net>
References: <DC8C0F88-1B43-4601-A3D1-2EEA812B89B9@newclarity.net>
 <9d3f9895-5ab6-1d75-4eb2-0ba93f13a8fe@gmail.com>
 <9D2698F0-49A4-4EA0-BEEE-552D28BE995A@newclarity.net>
 <CALKiJKqCT2D4hmoLDBOTH9EHpZJeqDo-G7YXGutEY3uz647grg@mail.gmail.com>
 <C0F0F6B7-697E-4677-888E-8D8C569A01D6@newclarity.net>
Message-ID: <374ad5f6-be02-8762-c4c3-12cf34e70cad@gmail.com>
Date: Tue, 29 Oct 2019 21:49:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <C0F0F6B7-697E-4677-888E-8D8C569A01D6@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Optional pre-compiler for PHP8?
From: rowan.collins@gmail.com (Rowan Tommins)

On 29/10/2019 19:04, Mike Schinkel wrote:
>> Note that this was exactly what "P++" was intended to avoid - the two
>> dialects would exist in the same engine, and get the same performance and
>> security enhancements.
>
>     It could also be one engine, it just seemed like that coupling
>     would be more problematic than separating them.
>

I think the problem is that as soon as you have two engines targeting 
different feature sets, it will be hard to persuade people to spend 
equal attention on both. If all the new features end up being added to 
one engine, the other one is going to increasingly feel like "legacy 
mode", rather than "equal but different".



>> Both of these are reasons to have some sort of "strict mode", but not for
>> tying it to some other feature.
>
>     I don't understand your reply, but maybe it is moot considering
>     the rest of the dialog?
>
>     What we have today is a rock vs a hard-place, and no one wants to
>     give even a millimeter.
>
>     So, if this is not a viable solution in your mind to break the
>     logjam between BC and the desire for strictness-in-all-the-things,
>     do you have an alternate, better proposal?
>

The idea of an "extra strict" and/or "less backwards compatible" mode 
has been mentioned on the list several times, but you're the first to 
suggest making it mandatory when using an otherwise unrelated 
performance feature.

It would be much better to keep it separate, and opt into it via a 
declare() statement, or a package configuration, or a file extension. 
There have been proposals for a single flag, lots of separate flags, a 
complete "P++" dialect, or bundles of settings ("Editions").

Whatever the approach, a key goal in my mind should be to maximise the 
compatibility between the two, and share as much implementation as 
possible. Both/all modes should get the same performance improvements, 
except where the actual features are necessarily slower or faster.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]