Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121764
MIME-Version: 1.0
References: <CAH5C8xX5Wzbm1eerFJJ5hCZdUU8rci8NhBwkSwprRKAG531G7Q@mail.gmail.com>
 <CAEKnhAFDYiPoKwjj2J6akEaZ6WgHkaYia9su_fNQGSKidCt=aw@mail.gmail.com>
 <CAFPFaMLWSW+eu8c0v91KLbcZJqcKKDbYZ3OthtNXk805p0AvQA@mail.gmail.com>
 <04DC3709-3B46-41C0-976E-E6AB28BC0D34@edison.tech> <CAFPFaMK+Rm5W3j_W5e3Cjc=HNBcA=U-Va5qbuOXz+q1ccpvswg@mail.gmail.com>
In-Reply-To: <CAFPFaMK+Rm5W3j_W5e3Cjc=HNBcA=U-Va5qbuOXz+q1ccpvswg@mail.gmail.com>
Date: Wed, 22 Nov 2023 18:52:53 -0300
Message-ID: <CADK1yXLuypfyzAaa+QRVuGJ__da87=-h7a3tSXqq3jL_Xm1c9A@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: Mike Schinkel <mike@newclarity.net>, Jakub Zelenka <bukka@php.net>, 
	=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000699d2060ac4c0b0"
Subject: Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion
From: deleugyn@gmail.com (Deleu)

--0000000000000699d2060ac4c0b0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 22, 2023 at 2:08=E2=80=AFPM 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 201=
2.
> 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 chang=
es
> to the language, recent or not, that break compatibility.
>
> Go even has a cave out that they *may* release a Go 2 specification, whic=
h
> does not guarantee any backwards compatibility with Go 1. [1]
> Even if the current lead engineer says this is "never" going to happen, t=
he
> 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 check=
s
> 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=3D0)`, it could be used fo=
r
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.

--=20
Marco Deleu

--0000000000000699d2060ac4c0b0--