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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
