Re: PHP 8 next?

On Sun, Jun 24, 2018 at 11:24 AM Rowan Collins <rowan.collins@gmail.com> wrote: > > On 24 June 2018 15:31:18 BST, Levi Morrison <levim@php.net> wrote: > >My position stands: I *strongly* object. If we rush to PHP 8 then it > >will be at least 4-5 more years before we have another chance for > >breakages in PHP 9. We can add features yearly. > > Then when is the right time? We already have a list of deprecated features, and I believe some > have already waited 4 years. > > Are there particular breaking changes that you think would be ready in 2 years time that > wouldn't be ready in 1? Certainly. Large breaks require multi-year planning and multiple releases to add migration paths, documentation and training, deprecations, etc, before the change itself happens. If PHP 8 is the next release then we've missed the window for deprecations and warnings (mostly; feature freeze is imminent). I wish our symbol tables were merged. If they were they we could nicely solve some issues: // this tries to use a constant of name 'functionname' array_map(functionname, $input); // this uses an object property instead of a method array_map($object->methodname, $input); // requires parens; eg ($this->property_which_is_callable)(...$args) $this->property_which_is_callable(...$args); Another: people would like autoloading to work with functions and constants instead of just classes/interfaces/traits. It's also annoying that we have to re-implement features for every symbol type "use function", "use const", whereas classes just say "use". It's also annoying that our symbols do not behave the same when they are missing; again, unifying the behaviors is a bonus and lays the foundation for other features. Whether you actually want these features or not, hopefully you can agree that these things cannot be dropped into PHP 8 without warnings and deprecations, which is our most reliable way of telling users when code will break or change.