Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106512
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
In-Reply-To: <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
Date: Fri, 9 Aug 2019 23:57:28 +0200
Message-ID: <CANS-=pfaWqeSXtX3H-Ku1eW-18=M2_td3AekVJ-1QdHc39uMLg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Zeev Suraski <zeev@php.net>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000392cf5058fb6446a"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: kjarli@gmail.com (Lynn)

--000000000000392cf5058fb6446a
Content-Type: text/plain; charset="UTF-8"

On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> This is basically what I have been advocating for a while now already,
> somewhat hidden between all the other noise of the "namespace-scoped
> declares" thread. The model I would like to follow are Rust editions (
> https://doc.rust-lang.org/edition-guide/editions/index.html). In PHP right
> now, the way to do this technically would be based on a
> declare(edition=2020) in every file. I was hoping to make this a
> per-package declaration instead, but haven't found the perfect way to do
> this right now.
>
> I think that introducing this kind of concept for PHP is very, very
> important. We have a long list of issues that we cannot address due to
> backwards compatibility constraints and will never be able to address, on
> any timescale, without having the ability of opt-in migration.
>
> I do plan to create an RFC on this topic.
>
> Nikita
>

Hi,

After reading several replies and discussing several solutions, I'd like to
add my feedback to this. Regardless of implementation details, I prefer a
structure similar to the control we have over strict types. I like the idea
of being able to configure this per file, or per "package" (however this
may be implemented). The benefit here is that a certain file, or package,
could run in fancy mode, while (possibly legacy) application code can run
in classic mode. I do assume here that it's primarily behavior changes,
perhaps adding/removing/deprecating functions/classes etc, or throwing
exceptions instead of returning false. I expect that both would be using
the same parser in this scenario.

I'm not exactly sure if this will fix the backwards compatibility concerns
though, at some points BC will have to broken to advance in the classic
mode. Who will decide when a feature should be added in classic mode, or a
behavioral change should be done? One could assume that anything that's not
backwards incompatible could be added without issues. Would that mean that
only "big" BC breaking changes would be added to the fancy version? Would
we be looking at the removal of `==` comparisons in this fancy mode for
example?

Regards,
Lynn van der Berg

--000000000000392cf5058fb6446a--