Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:106468 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 36191 invoked from network); 9 Aug 2019 09:25:50 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 9 Aug 2019 09:25:50 -0000 Received: from [10.39.115.59] (ppp-223-24-166-223.revip6.asianet.co.th [223.24.166.223]) by mail1.25mail.st (Postfix) with ESMTPSA id 530F9604CD; Fri, 9 Aug 2019 06:53:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (16F203) In-Reply-To: <78d32666-9a9d-43ac-8c72-930d11cc1dff@Spark> Date: Fri, 9 Aug 2019 13:52:56 +0700 Cc: Nikita Popov , Zeev Suraski , Internals Content-Transfer-Encoding: quoted-printable Message-ID: <4E575945-A562-4749-9CFB-147741B25ACA@koalephant.com> References: <78d32666-9a9d-43ac-8c72-930d11cc1dff@Spark> To: Brent Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy From: php-lists@koalephant.com (Stephen Reay) > On 9 Aug 2019, at 12:11, Brent wrote: >=20 > Hi Zeev >=20 > 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 a= nalysis about the pros and cons of the two paths to take: a sister language v= s. 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 de= cision. >=20 > There's one thing I haven't seen mentioned yet though: what about the adde= d workload for the core developers? You'll have to maintain two implementati= ons of PHP, be it in the same runtime. Is this a load the core developers ar= e able to carry? Aren't you afraid that development of the "old" version of P= HP would quickly decline? If that were to happen, there's little difference i= n tagging a new major release with the breaking changes/cleanup we want. >=20 > Lastly, how do you envision interop between this two sister languages? Wou= ld a "normal" composer package be able to run in P++ ? You did mention P++ w= ould share the same runtime, extensions, etc, but whether the runtime would b= e able to switch between the old and new version depending on the code wasn'= t clear to me. >=20 > Kind regards > Brent >> On 8 Aug 2019, 23:59 +0200, Zeev Suraski , wrote: >>> On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrot= e: >>>=20 >>>> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wro= te: >>>>=20 >>>> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote: >>>>=20 >>>> 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/ >>>> >>>> edition-guide/editions/index.html >>>> ). In PHP >>>> right now, the way to do this technically would be based on a >>>> declare(edition=3D2020) in every file. I was hoping to make this a >>>> per-package declaration instead, but haven't found the perfect way to d= o >>>> this right now. >>>>=20 >>>> 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, o= n >>>> any timescale, without having the ability of opt-in migration. >>>>=20 >>>> I do plan to create an RFC on this topic. >>>>=20 >>>=20 >>> After reading your mail again, I think what I have in mind is maybe quit= e >>> different from what you have in mind after all, even if the motivation a= nd >>> purpose (language evolution without breaking legacy code) is the same. >>>=20 >>=20 >> I'd describe my motivations quite differently than that. >>=20 >> 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. >>=20 >> 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 a= t >> all what I'm talking about. This is also why an edition named 'PHP2020' i= s >> somewhat problematic - as it implies you're behind if you're not using it= . >>=20 >> My goal is to have two sister languages, with both PHP and P++ being equa= l >> among equals, and not PHP being the 'dead language walking' and P++ being= >> the end goal of everything. >>=20 >> 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 PH= P. >>>=20 >>=20 >> Not quite - it doesn't just happen to interoperate with PHP. It shares th= e >> 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. >>=20 >> I don't think that's a direction we should be going down. >>>=20 >>=20 >> Oh well :| >>=20 >>=20 >>> 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 yo= u >>> want to rebrand your language every five years ;) What we need is someth= ing >>> that is sustainable in the long term. >>>=20 >>=20 >> 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 a= re >> they're fundamentally unhappy about, and moving to a 'let's redo the >> language every five years'. >>=20 >>=20 >>> I also don't like the idea of rebranding as a new language. While PHP ha= s >>> 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 thre= ad, >>> a new edition could require & annotations at call-sites and gain all the= >>> benefits that entails without breaking the ecosystem. >>>=20 >>=20 >> 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 ca= n >> 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 P= HP >> as we currently know it. >>=20 >> 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.= >>=20 >> Thanks, >>=20 >> Zeev As a userland dev (both writing apps and maintaining a library/framework) I=E2= =80=99m glad there is discussion about how to move forward, and if I underst= and his suggestion correctly, Nikita=E2=80=99s approach would be that langua= ge features are fundamentally enabled by declare statements as strict_types i= s now, but that there=E2=80=99d also be =E2=80=9Ccollections=E2=80=9D that c= an 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 a= nd course grained choices on language features. However I=E2=80=99m also not sure how that particular approach would =E2=80=9C= solve=E2=80=9D the open tags issue that (partly) started this discussion. I g= uess that whatever sets NS-based declares could define what tag is accepted f= or later loaded files, but that just moves an ini setting into a declare rea= lly. I=E2=80=99ll admit I can=E2=80=99t quite picture how Zeevs proposal would wo= rk, and honestly I have concerns it=E2=80=99d turn into a Python2 vs Python3= scenario. It would (seemingly) solve the open tags issue more easily though= . Cheers Stephen=