(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 already, > 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 > possible so that people have no excuse for not upgrading besides laziness. > That's why there's such a (entirely legitimate) concern for BC breaks, > because every BC break is one more reason for people to not upgrade to a > supported release. absolutely. > Adding new functionality that doesn't break *existing* code is entirely > irrelevant. 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 out. 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 <la...@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 <chasepee...@gmail.com> wrote: > > > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings <andr...@dqxtech.net> > > > 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 that > > > > means). > > > > So, opt-in BC breaks. > > > > > > > That's not true at all. There are a ton of things that have been discussed > > > that will progress the language and don't require any sort of BC break. > > > Union types is one example. Support for Enums is another. > > > > > > Even if a BC break is required, it's not automatically a bad thing. > > > Whether > > > we are looking at plugging up a big security hole, getting rid > > > of/modifying > > > a rarely used feature, adding support for something that it's currently > > > 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 today. > > 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, they're > already on their own. > > The point, of course, is making that upgrade as much of a no-brainer as > possible so that people have no excuse for not upgrading besides laziness. > That's why there's such a (entirely legitimate) concern for BC breaks, > because every BC break is one more reason for people to not upgrade to a > supported release. > > What you're talking about is new language features; well-behaved code written > for PHP 5.2 should still run perfectly fine on 7.3, where the ?? operator is > quite well supported thank you and if people want to use your new module they > should damn well upgrade. (Drupal has had the ability to set a minimum 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 > functionality that doesn't break *existing* code is entirely irrelevant. > It's more around subtle changes to existing behavior, which are sometimes > worthwhile and sometimes not. > > Whether editions is the "right" way to balance "don't break 1 million lines > 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 know. > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
