On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov <nikita....@gmail.com> wrote: > >> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski <z...@php.net> wrote: >> >> This is basically what I have been advocating for a while now already, >> somewhat hidden between all the other noise of the "namespace-scoped >> declares" thread. The model I would like to follow are Rust editions ( >> https://doc.rust-lang.org/ >> <https://doc.rust-lang.org/edition-guide/editions/index.html> >> edition-guide/editions/index.html >> <https://doc.rust-lang.org/edition-guide/editions/index.html>). In PHP >> right now, the way to do this technically would be based on a >> declare(edition=2020) in every file. I was hoping to make this a >> per-package declaration instead, but haven't found the perfect way to do >> this right now. >> >> I think that introducing this kind of concept for PHP is very, very >> important. We have a long list of issues that we cannot address due to >> backwards compatibility constraints and will never be able to address, on >> any timescale, without having the ability of opt-in migration. >> >> I do plan to create an RFC on this topic. >> > > After reading your mail again, I think what I have in mind is maybe quite > different from what you have in mind after all, even if the motivation and > purpose (language evolution without breaking legacy code) is the same. > I'd describe my motivations quite differently than that. First, I want to point out that my very first motivation was in fact a human one - hence the subject line. I think there's substantial value in finding a solution for the constant contention on internals, without neither camp giving up on their principals and beliefs. Secondly - the current language-base of PHP (7.x) won't be 'legacy'. I think there's going to be a lot of new code written in it, and I think a lot of people would prefer it over P++ - even in 5 or 10 years. Again, C/C++ is a very good analogy here. If one camp remains 'missionary' about forcing the other camp to assimilate as the long term goal - that's not at all what I'm talking about. This is also why an edition named 'PHP2020' is somewhat problematic - as it implies you're behind if you're not using it. My goal is to have two sister languages, with both PHP and P++ being equal among equals, and not PHP being the 'dead language walking' and P++ being the end goal of everything. In particular, you seem to have a pretty strong focus on introducing a > "new" language with a new name that just happens to interoperate with PHP. > Not quite - it doesn't just happen to interoperate with PHP. It shares the same runtime; It shares the same extensions; It shares many of the same tools; And most importantly - it's very similar in its syntax. Again, here too, the C/C++ analogy works really well. Would you say C++ is a new language that just happens to interoperate with C? It's obviously a lot more than that. I don't think that's a direction we should be going down. > Oh well :| > One of the larger issues with that is that it only works once: You have > one BC break point going between PHP and PHP++, but that's it. Unless you > want to rebrand your language every five years ;) What we need is something > that is sustainable in the long term. > I think that the one, big-scoped compatibility breakage is a feature, not a bug. At the risk of sounding like a broken record - the C/C++ analogy works well here too, this time specifically C++. You can evolve the new language - even substantially - but C++ always stayed C++ and C always stayed C. Yes, there's C++03, C++11, etc. - but at the end of the day - the language is C++, and these editions are similar to the evolution we introduce in feature releases. If your goal is to have major BC breaks every five years, then I doubt we can find common grounds. But I'm not sure how many folks here think that's a good idea either. There's a big gap between thinking we should break away from 20+ year old chains that are they're fundamentally unhappy about, and moving to a 'let's redo the language every five years'. > I also don't like the idea of rebranding as a new language. While PHP has > a bad reputation, I really don't think that introducing PHP++ will do > anything positive to that. PHP should stay PHP. The core language should > remain the same across all editions/epochs/whatever -- just with the > possibility of addressing specific issues. As discussed in a recent thread, > a new edition could require & annotations at call-sites and gain all the > benefits that entails without breaking the ecosystem. > I'm sorry to hear that. In this particular case I really think you're wrong (FWIW) - rebranding can actually do a lot of positive things. It can stir interest. It can result in articles being written. It can make developers, development leaders and companies who have ruled out PHP reconsider their decision since "this is no longer PHP". A new version of PHP, or for that matter a new edition of PHP - will simply not have the same impact. As much as we're all technical people here, marketing matters. And in this particular case - this type of positioning does make sense - as with many of the proposed changes - this really is no longer PHP. Another thing it can also do is radically simplify the end-user understanding of our vision of what goes where, and what's in store for PHP as we currently know it. I'm truly hopeful that others on the list (and perhaps you as well) evaluate this proposal with an open mind. I did run by a few folks (from the 'other' camp) prior to publishing it, and response was very positive. Thanks, Zeev
