On Mon, Apr 10, 2023 at 7:03 PM Larry > > Again, let's assume there is no question it will happen. The question for > you: What process for making it happen would you consider sufficiently > BC-friendly? What timeline? What level of pre-review? What reasonable > process would you propose that maximizes the ability of the language to > remove its own design bugs while minimizing the hassle for responsible > developers? (Responsible: They actually pay attention to upcoming changes > and prepare for them in less than 7 years.) >
What I would consider sufficiently BC-friendly is having a cut-off. Any code written by the previous generation (folks that are long gone or retired by now) continue to work as it used to while I catch up in removing it from production systems. If the code was written in 2010 or earlier and uses $a++; with the expectation that it will result in "b", leave it as-is. If the code was written in 2018 or earlier, feel free to break it. Several discussions around this have happened, but unfortunately none landed anywhere. Whether it be a new opening tag of <php8 or <php9 or a new directive/edition. In fact, if we're talking about my opinion only (what works for me personally), make this change behind the existing strict_types=1. There's no "PHP 5 Era" code under my responsibility that has strict_types enabled so if it were up to me, make every BC break you want behind strict_types=1 but keep PHP with strict_types=0 running without BC breaks for about 10 years. When PHP libraries break BC, it often comes with options of 1) extend the original class and override something 2) opt-in to old behavior 3) register a callback that can be used to define the old behavior back in or 4) work with an interface or 5) last resort to fork the library if taking the maintenance burden is worth it. I don't have any of these options when PHP breaks BC. Yes, old PHP has some bad and weird behaviors. I don't like it, you don't like it, nobody likes it. I don't want to use those weird stuff, but I'm doing the best I can to replace every single line of old code that has been written in an era that "best practices for PHP development" were not what you and I know today. Take PHP 7.2 deprecation of counting non-countable arguments. Could that broken code have been taken out of PHP Core, made it available as a legacy PHP extension and just kept alive for the foreseeable future? Can we have an additional PHP extension that allows us to still pass null to non-nullable internal function parameters? Something like php56_substr(). I don't mind if its BC breaks are opt-in or opt-out as long as we can have a single cut-off and make it easier for us to keep running legacy code until we succeed in decommissioning it. In fact, if you wanted to deprecate `readonly` in PHP 8.3 because (as you've said it), it's a broken behavior that prevents you to move forward with asymmetric visibility or property accessors, I wouldn't care because readonly was something introduced in a time that the code being written using it has 100% test coverage and static analysers protecting it. It's easier for me to deal with any BC breaks of PHP 7.1 or higher than it is to deal with deprecations of PHP 5.6 or lower.
