Re: Bringing Peace to the Galaxy

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> wrote: > > On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings <andreas@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