> On 9 Aug 2019, at 12:11, Brent <bre...@stitcher.io> wrote: > > Hi Zeev > > Happy to see this proposal pop up, it's good to know that the "other side" is > also open for long-term solutions. I think there needs to be a thorough > analysis about the pros and cons of the two paths to take: a sister language > vs. Nikita's proposal. To me, a userland developer, both solutions would have > the same result in the end, so I trust internals to make a well-informed > decision. > > There's one thing I haven't seen mentioned yet though: what about the added > workload for the core developers? You'll have to maintain two implementations > of PHP, be it in the same runtime. Is this a load the core developers are > able to carry? Aren't you afraid that development of the "old" version of PHP > would quickly decline? If that were to happen, there's little difference in > tagging a new major release with the breaking changes/cleanup we want. > > Lastly, how do you envision interop between this two sister languages? Would > a "normal" composer package be able to run in P++ ? You did mention P++ would > share the same runtime, extensions, etc, but whether the runtime would be > able to switch between the old and new version depending on the code wasn't > clear to me. > > Kind regards > Brent >> On 8 Aug 2019, 23:59 +0200, Zeev Suraski <z...@php.net>, wrote: >>> 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
As a userland dev (both writing apps and maintaining a library/framework) I’m glad there is discussion about how to move forward, and if I understand his suggestion correctly, Nikita’s approach would be that language features are fundamentally enabled by declare statements as strict_types is now, but that there’d also be “collections” that can be set on, to enable multiple language features at once, AND ideally both single declares and the higher level collections would be able to be set at a level more broad than file based (eg namespace based). I like that this approach gives us a way forward with options for both fine and course grained choices on language features. However I’m also not sure how that particular approach would “solve” the open tags issue that (partly) started this discussion. I guess that whatever sets NS-based declares could define what tag is accepted for later loaded files, but that just moves an ini setting into a declare really. I’ll admit I can’t quite picture how Zeevs proposal would work, and honestly I have concerns it’d turn into a Python2 vs Python3 scenario. It would (seemingly) solve the open tags issue more easily though. Cheers Stephen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
