Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106822
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
 <CAF+90c_etW4HU1ae9TLaZzKtaLtYbfkq2TKy4ydKOM=3XDRDXw@mail.gmail.com>
 <CAH0Uv3GoB7d79Zn-wid_uxQHKOesHtDzgm6a_yuScjB0nfrVRQ@mail.gmail.com>
 <CAPKYkKyREMkWaNBx5ZZVk-=gc0DML7rTctSenzyZwJZTgCckjA@mail.gmail.com>
 <CAH0Uv3H8cXPpYioqp=6QwofBFQ5v5VL2ZJHttcSPZVn3Bo5k7A@mail.gmail.com> <fea77595-62e1-4440-afe8-ecd4d31d3c02@www.fastmail.com>
In-Reply-To: <fea77595-62e1-4440-afe8-ecd4d31d3c02@www.fastmail.com>
Date: Sat, 31 Aug 2019 03:41:02 +0200
Message-ID: <CAH0Uv3G3Suh91k+2_ThXn3SSKSxvd36EQeNgzy17mGVUeoeb9w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: Steffen via internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: andreas@dqxtech.net (Andreas Hennings)

(I hope this exchange is not getting too Drupal-specific.
I imagine the same concerns would apply in any project that uses a lot
of 3rd party code, and that is affected by framework versions and
generations of framework ecosystems.)

> Someone running their code on an old and unsupported PHP version is alrea=
dy, well, unsupported.

This is true, but:
- The problem already applies within a range versions that are
officially supported at a given time. E.g. the ?? operator came out
long before PHP 5.6 became unsupported. At the same time, major Drupal
7 modules had to slowly catch up. And some less popular modules never
did. As long as a site was not fully ready for PHP 7.x, developers
could not use the ?? operator, or use any 3rd party code that uses the
?? operator.
- There might be reasons preventing people from updating. You already
agree, so nothing to argue here.

> The point, of course, is making that upgrade as much of a no-brainer as p=
ossible so that people have no excuse for not upgrading besides laziness.  =
That's why there's such a (entirely legitimate) concern for BC breaks, beca=
use every BC break is one more reason for people to not upgrade to a suppor=
ted release.

absolutely.

> Adding new functionality that doesn't break *existing* code is entirely i=
rrelevant.  It's more around subtle changes to existing behavior, which are=
 sometimes worthwhile and sometimes not.

These are two sides to the same coin:
- New features which are only available in a new language version.
- Old language "features" (or in most cases "bad practices that used
to be unpunished") which only work in older PHP versions. Of course
this is only a problem if updating or fixing this code would be
costly.

This creates an interoperability problem between old code (if not
fixed or updated) and new code (3rd party or custom), because there is
no engine version that allows them to coexist in the same project.

Realistically, a large project or ecosystem, like a historic building
or a city, will have older and newer parts. Parts you want to touch
and work on, and other parts you rather leave alone.

For unsupported versions we can always say "your fault", but even
within the supported version range there are these interoperability
limitations.
The trade-off on a specific project might be somewhere in the middle:
Use a PHP version that is not the newest but also not the oldest. Fix
or update the worst of the legacy code, but avoid new language
features until the entire system is ready for it.

Of course in the world of technology we cannot expect that a project,
or a framework ecosystem, stays around forever. The language version
is only one variable in the equation. At some point your framework, or
the specific version you are using, will become unsupported.
At some point the entire system needs a rewrite, throwing some old stuff ou=
t.

The "editions" idea (or how I imagine it) would not save you from the
need for a periodic rewrite.
But it would allow developers to already use the new language features
and new 3rd party libraries. So they might already write the code that
will later be used in the new rewritten system.

E.g. imagine PHP gets generics one day.
With "editions" (how I imagine them), you could already use generics
in your own custom code, or use composer packages that rely on
generics, in your legacy codebase. If you envision a rewrite that
relies heavily on generics, you can already develop a lot of this code
in the older version of the project.

A project which nowadays would run a PHP version somewhere between the
oldest and the newest, would now be able to run the latest PHP version
most of the time.

On Sat, 31 Aug 2019 at 02:31, Larry Garfield <larry@garfieldtech.com> wrote=
:
>
> On Fri, Aug 30, 2019, at 1:56 PM, Andreas Hennings wrote:
> > On Fri, 30 Aug 2019 at 19:38, Chase Peeler <chasepeeler@gmail.com> wrot=
e:
> > > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings <andreas@dqxtech.ne=
t>
> > > wrote:
> > > > The only way to make this possible is to either deny all progress, =
or
> > > > to make a distinction on file level (or "package level", whatever t=
hat
> > > > means).
> > > > So, opt-in BC breaks.
> > > >
> > > That's not true at all. There are a ton of things that have been disc=
ussed
> > > that will progress the language and don't require any sort of BC brea=
k.
> > > Union types is one example. Support for Enums is another.
> > >
> > > Even if a BC break is required, it's not automatically a bad thing. W=
hether
> > > we are looking at plugging up a big security hole, getting rid of/mod=
ifying
> > > a rarely used feature, adding support for something that it's current=
ly
> > > impossible to do, or just doing something that adds tremendous value =
to the
> > > language. In all of those cases the impact of the BC break should be
> > > weighed against the benefits.
> >
> > The problem and trade-offs I am describing are already impacting me tod=
ay.
> > I am working on a Drupal 7 site with lots of legacy code, and I am
> > developing Drupal 7 contrib modules that I want to be available to a
> > large audience.
> >
> > In one of these modules I initially used the ?? null coalesce operator.
> > Then I had to replace all of the instances of ?? with the more verbose
> > old-school code, to make it compatible with older PHP, because there
> > are still enough Drupal 7 installations out there which have not
> > upgraded to PHP 7 yet.
> > I also had issues with old 3rd party libraries, which stood in the way
> > of PHP version upgrade.
> >
> > In a world with "editions" per file or per package, such projects
> > could more easily use the newest PHP version, while the old libraries
> > would continue working.
>
> That's a somewhat different issue.  Someone running their code on an old =
and unsupported PHP version is already, well, unsupported.  They're running=
 code with known unfixed security issues, most likely, and they take their =
chances.  If they won't upgrade to a supported PHP version then, frankly, t=
hey're already on their own.
>
> The point, of course, is making that upgrade as much of a no-brainer as p=
ossible so that people have no excuse for not upgrading besides laziness.  =
That's why there's such a (entirely legitimate) concern for BC breaks, beca=
use every BC break is one more reason for people to not upgrade to a suppor=
ted release.
>
> What you're talking about is new language features; well-behaved code wri=
tten for PHP 5.2 should still run perfectly fine on 7.3, where the ?? opera=
tor is quite well supported thank you and if people want to use your new mo=
dule they should damn well upgrade.  (Drupal has had the ability to set a m=
inimum PHP version for a specific module for over a decade; I know, I wrote=
 that functionality. :-) )
>
> > I also had issues with old 3rd party libraries, which stood in the way
> > of PHP version upgrade.
>
> This is the part that is of concern to this discussion.  Adding new funct=
ionality that doesn't break *existing* code is entirely irrelevant.  It's m=
ore around subtle changes to existing behavior, which are sometimes worthwh=
ile and sometimes not.
>
> Whether editions is the "right" way to balance "don't break 1 million lin=
es of 15 year old code" with "this behavior is bad and we all know it" and =
with "this behavior leads to sloppy code that is prone to bugs", I don't kn=
ow.  I'm not sure what my stance is on these questions yet.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>