> On Oct 28, 2019, at 6:00 AM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > Current tools tend to actually work on a directory level, because you don't > actually know what namespaces are involved until after you've loaded it, > and a file can include code for two completely separate namespaces. My > thinking was that a package would pre-define the full list of files that > define it, with no auto-loader, and no conditional definitions evaluated at > run-time. As Benjamin points out, this is closely related to preloading.
I would rather a tool that did not require specifying the files. I personally would be fine with one that used a directory as the demarcator, and even if it only worked when you put your namespace in another directory it won't work. > And what if you want simplicity *and* performance? Most of the things > people want to make strict about the language don't make it faster, so if > we limited "pre-compiled mode" to be strict, we'd be making a deliberate > choice to group objectively good things (fast vs slow) with subjective > preferences (strict vs simple). That pretty clearly marks strict mode as > "the better way". At the risk of being too flippant, I defer to the wisdom on that great philosopher Mick Jagger and say you can't always get what you want... But seriously, at some point tradeoffs have to be made to see any forward progress. What we have not found before was a good tradeoff between strict and BC. Maybe this it is? After all, while not all strict things are about performance but many things that enable performance are strict. > That sounds like the worst kind of fork: two different engines, running two > different dialects of the language. At that point, you might as well just > switch to Hack. That feels like an over-reaction. Hack has purposely diverged from PHP and requires a different runtime than PHP. The idea I was proposing is that the PHP runtime be one but operates in two different modes — one mode per "engine" — and the goal of two different modes would to be to stay more similar than different, but allow one of them to have BC breaks. > 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. That said, I'm not skilled enough in PHP internals to implement it (yet?) so I can only speak to it at a high level. >> The advantage would be two-fold: >> >> 1. Backward compatibility >> >> 2. Allowing PHP to continue to meet the needs of new/less-skilled >> programmers and/or people who want a more productive language for smaller >> projects that do not need or want all the enterprisey type-safe features. > > 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? -Mike
