On Wed, Nov 22, 2023 at 10:53 PM Deleu <deleugyn@gmail.com> wrote:
>
> On Wed, Nov 22, 2023 at 2:08 PM G. P. B. <george.banyard@gmail.com> wrote:
>
> > On Wed, 22 Nov 2023 at 07:36, Mike Schinkel <mike@newclarity.net> wrote:
> >
> > > On Nov 21, 2023 at 11:33 PM, <G. P. B. <george.banyard@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
Hey Marco,
I think the biggest issue with that strategy is that you end up
endorsing projects that PHP cannot control. This may not be a bad
thing, but personally, I'd love to see PHP start adopting these kinds
of projects as officially maintained by PHP. For example, composer
could be forked or brought over to the PHP organization and then if
PHP wants to change how autoloading works ... they can just change it
and implement a migration path in composer/rector/whatever. All these
tools maintained by volunteers over the years would benefit from being
able to have important conversations before a feature is even
developed; even be able to suggest changes to the feature that would
allow for seamless migrations.
Imagine installing PHP 9.0 and then just running `php
--migrate-from=8.2` and having it run rector + composer (maybe even
static analysis before and after to give you issues) migration scripts
on an entire codebase.
Right now, you need to know what to do and how to use it. You may not
even know these tools exist or what to search for to find them,
particularly if you are new to PHP.
Robert Landers
Software Engineer
Utrecht NL
