On Sun, Jun 24, 2018 at 11:24 AM Rowan Collins <[email protected]> wrote:
>
> On 24 June 2018 15:31:18 BST, Levi Morrison <[email protected]> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php