On Wed, Nov 22, 2023 at 2:08 PM G. P. B. <george.bany...@gmail.com> wrote:
> On Wed, 22 Nov 2023 at 07:36, Mike Schinkel <m...@newclarity.net> wrote: > > > On Nov 21, 2023 at 11:33 PM, <G. P. B. <george.bany...@gmail.com>> > wrote: > > > > What is the point of a major release if we cannot even do such a BC > break? > > We don't even know when PHP 9.0 is going to happen yet. > > > > > > I have been using Go for about four years now and it seems they have > > gotten the backward compatibility issue nailed, and that pays great > > dividends in developer confidence in the language, i.e.: > > > > > > > https://www.reddit.com/r/golang/comments/17v4xja/anyone_face_issues_when_updating_version_of_go/ > > > > They recently explained in depth how they do it: > > > > https://go.dev/blog/compat > > > > Also see: > > > > https://thenewstack.io/how-golang-evolves-without-breaking-programs/ > > > > Although Go is compiled and PHP is not, I think there still may be > > significant insight that can be gained for PHP by studying how Go is > > handling it and applying any lessons learned. > > > > Go is a "new" programming language, with its 1.0.0 version being from 2012. > It was also designed from the ground up. > > PHP on the other hand wasn't designed, but the language grew organically, > and is 28 years old. > Comparing it to Go, in my opinion, makes no sense. > > We should be comparing ourselves to languages of that age or older, the > most famous example being Python, which did a major BC break between its > version 2 and 3. > But Fortran, C, Perl (with Raku), and for sure others have all made changes > to the language, recent or not, that break compatibility. > > Go even has a cave out that they *may* release a Go 2 specification, which > does not guarantee any backwards compatibility with Go 1. [1] > Even if the current lead engineer says this is "never" going to happen, the > cave out still exists. > > More importantly, it is possible to write cross compatible code, even > without changing anything about is_resource(), if we convert streams to > opaque objects. > It might be tedious and one might need to have redundant instanceof checks > with is_resource() if one does not want to check for a false return, or > duplicate checks for closed resources. > But it is possible, which was *not* the case for Python 2 and 3 as it > changed fundamentally how strings behaved. > > Finally, I think people would have more confidence in the language if it > stopped coming with various foot guns included that need to be explicitly > kept in check by using external tools such as static analysis tools, or > code style tools. > And removing those, or making the language overall more coherent and > consistent, requires us to break backwards compatibility. > > Sincerely, > > Gina P. Banyard > I sympathise with both sides on this topic. As a Software Engineer, not breaking 10-30 years of BC promise is unsustainable, but as a PHP user BC breaks have a heavy impact on legacy codebase written 10~20 years ago. A lot of discussion has happened around this subject, but unfortunately no consensus is ever reached. I've talked about increasing the stability and the pool of maintainers by providing PHP Packages under PHP namespace ( https://externals.io/message/120335#120354). There were a lot of discussions on language evolution and editions that ultimately didn't go much further. Given how much time has passed and how this subject is always present, I now look at this with the optics that both PHP internals devs and PHP users suffer from the same condition of dealing with legacy. Between 1990 up to 2010, give or take, the way software used to be built vastly differs from how software is built today and these old software can be very hard to decommission given their lack of automation tests and inability to be statically analysed. With today's practices, I believe it's easier to introduce BC breaks that affect software written after 2018. And since I believe that, it's a natural consequence for me to believe that if PHP introduced a new `declare(backward_compatibility=0)`, it could be used for users to signal to the engine that 1) we're writing this file after 2023 and 2) we will cover this file with automation tests and/or static analysis tools. PHP Internals wouldn't need to make a huge big-bang BC break all-at-once. Every year new BC breaks could be introduced affecting only the "new engine version". The idea isn't to build several combination of "PHP Editions" as it was discussed in the past, but rather to have a consensus between PHP Internals and PHP Developers that a new Engine is constantly being developed, this engine will break compatibility with the past 20 years of PHP whenever PHP Internals manage to rebuild something (throughout multiple versions), a migration path assumes users will use of Rector, Static Analysers and PHPUnit and the old engine keeps the BC promise in order to allow old software to keep running, but is expected to degrade in performance and to only support new stuff if it has no added burden to internals. When such assumptions are made about userland, the concept of what's an acceptable BC break should be skewed in favor of helping PHP Internals. -- Marco Deleu
