Sorry for getting into this hot topic. Just wanted to add my two cents. > Really, the only targets we should be looking at, IMO, are: > > 1. Package-level visibility. > 2. Giving the compiler/optimizer/JIT a larger "scope" of code to > compile/optimize at once, so it can do smarter things. > > I think everything else is a distraction.
As a userland developer, I like one of the author's intentions - to allow writing modern PHP code without poor legacy, without opening tags, which will also enable the compiler to apply more magick and more optimizations. I could see it as a new file extension, for example, "phpx" and release it in PHP10. This will not drop BC and at the same time, users will have the opportunity to explicitly tell the compiler that they want to use the new format. The inclusion of old-style files will still be allowed. In the far future, we may feature-freeze old-style files and gradually migrate to the new ones. I personally support the movement from the current "plain-text template-first" language to a "coding-first" language, where files contain code by default. We already support multiline raw strings in PHP code so the usage in templates should not suffer. Or it can even be simplified by introducing a better way to craft templates in the new "coding-first" format of PHP files. I also support the idea of having packages with private members, autoloading constants and functions without using classes. -- Alexander.
