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 [1] https://go.dev/doc/go1compat: > It is intended that programs written to the Go 1 specification will > continue to compile and run correctly, unchanged, over the lifetime of that > specification. At some indefinite point, a Go 2 specification may arise, > but until that time, Go programs that work today should continue to work > even as future "point" releases of Go 1 arise (Go 1.1, Go 1.2, etc.).
