Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.208.174 as permitted sender)
MIME-Version: 1.0
References: <CAF+90c8S3UK3xakJQ4eD1mCMvBAdms2_d5aDd0oOZHfi67Mn9Q@mail.gmail.com>
 <CAESVnVqKqLDcbrTwzSD2qms32kF3FROa6XGXp9UEgp2MLjDvPw@mail.gmail.com>
 <DM5PR0201MB35423C070BADA25899A12E1EAC740@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAFMT4NoB-WvTZ=tEqeMMOdt0vDxPLqe-_Ab93xqeKp1GXYjfew@mail.gmail.com>
 <DM5PR0201MB3542CDDEC128637665333A61AC4B0@DM5PR0201MB3542.namprd02.prod.outlook.com>
 <CAFMT4NrWt0APfRKaDc_m0WXT=i2+qRLZkDutVofHfrsk4dm3_w@mail.gmail.com> <4CD11D3A-D799-46CF-9DD0-E34552FB15CD@gmail.com>
In-Reply-To: <4CD11D3A-D799-46CF-9DD0-E34552FB15CD@gmail.com>
Date: Sun, 24 Jun 2018 15:26:24 -0600
Message-ID: <CAFMT4NqSR-zsZTaU84PFGo4cRpEXvKgzfQJ+poULtiH+RxAZiw@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] PHP 8 next?
From: levim@php.net (Levi Morrison)

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.