> On Oct 27, 2019, at 7:04 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote:
Thank you for your comments. > I chose the phrase "static analysis tool" deliberately, because I wanted to > think about the minimum requirements for such a tool, rather than its > long-term possibilities. Your points are all well-considered. To be clear, I wasn't stating the idea as a alternative to your idea, I was only stating that your comments inspired me to have the idea of a pre-compiler. IOW, I saw no reason both could not be done, one sooner and the other later. > However, combining those usefully may not be that easy. Also for clarity, I was not assuming existing OpCache would be 100% unmodified, I was talking about benefits that a pre-compiler could have and was less focused on ensuring it could slot into an existing OpCache implementation as-is. IOW, if it is worth doing it might be worth extending how the OpCache works. > So we'd probably need some built-in definition of a "package", which could be > analysed and compiled as one unit, and didn't rely on any run-time loading. That idea of a "package" came up during a debate on this list at least once, a few months ago, and I think it makes a lot of sense. And what I proposed effectively implies that namespaces would be treated like packages from the perspective of the compiler. But then again a new package concept might be needed in addition to namespaces, I am not certain either way. > Unlike P++, Editions, or Strict Mode, this would undeniably define that the > deprecated features were "the wrong way". I am not sure I cam agree that it would define them as the "wrong way." The way I would see it is there would be a "strict way" and an "unstrict way." If you prefer the simplicity of low strictness and do not need more/better performance or the benefits of type-safety that are needed for building large applications, then the "right way" would still be the "unstrict way." And the non-strict features would not be "deprecated" per-se, they would instead be disallowed for the strict (compiled) way, but still allowed for the unstrict (interpreted) way. > If the engine had to support the feature anyway, I think we are talking two engines; one for compiling and another for interpreting. They could probably share a lot of code, but I would think it would still need to be two different engines. > I'm not sure what the advantage would be of tying it to "compiled vs > non-compiled", rather than opting in via a declare() statement or package > config. 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. Frankly it is this advantage which is the primary reason I though to send a message to the list. The chance to have the benefit of strictness and high performance for more advanced PHP developers while still having full BC for existing code and for beginner developers seemed highly compelling to me. -Mike
