[RFC] [Discussion] Resource to object conversion

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