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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
