Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106819
MIME-Version: 1.0
References: <CAJHtznz+vMtytUxnf73L474TcDUqsZpTHLTnhHL4E53CCQdibA@mail.gmail.com>
 <CAF+90c-5CeZfyo2zBeoM63NDK-j2h6WTjvdT-yiKy040wVUm-w@mail.gmail.com>
 <CAF+90c_etW4HU1ae9TLaZzKtaLtYbfkq2TKy4ydKOM=3XDRDXw@mail.gmail.com> <CAH0Uv3GoB7d79Zn-wid_uxQHKOesHtDzgm6a_yuScjB0nfrVRQ@mail.gmail.com>
In-Reply-To: <CAH0Uv3GoB7d79Zn-wid_uxQHKOesHtDzgm6a_yuScjB0nfrVRQ@mail.gmail.com>
Date: Fri, 30 Aug 2019 13:37:47 -0400
Message-ID: <CAPKYkKyREMkWaNBx5ZZVk-=gc0DML7rTctSenzyZwJZTgCckjA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004e97a2059159157f"
Subject: Re: [PHP-DEV] Bringing Peace to the Galaxy
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000004e97a2059159157f
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 30, 2019 at 12:39 PM Andreas Hennings <andreas@dqxtech.net>
wrote:

> I would very much like to see "editions" or "generations".
>
> The only way to make this possible is to either deny all progress, or
> to make a distinction on file level (or "package level", whatever that
> means).
> So, opt-in BC breaks.
>
> That's not true at all. There are a ton of things that have been discussed
that will progress the language and don't require any sort of BC break.
Union types is one example. Support for Enums is another.

Even if a BC break is required, it's not automatically a bad thing. Whether
we are looking at plugging up a big security hole, getting rid of/modifying
a rarely used feature, adding support for something that it's currently
impossible to do, or just doing something that adds tremendous value to the
language. In all of those cases the impact of the BC break should be
weighed against the benefits.

There have been two proposals recently that have been contentious. Short
tag removal and the current RFC for making undeclared variables throw
errors. In both cases the arguments against these changes were not just a
flat "BC BAD" argument. They all were about the impact of such BC breaks in
comparison to what would be gained. In the case of the undeclared
variables, it's also being argued that we just shouldn't do it because it
gets rid of a feature of the language that some people see as a good
feature. To paint either one of them as an indication that we can't every
do anything that causes a BC break is just flat out false.

I'm not saying what you are proposing here is good or bad. I just wanted to
comment on this particular assertion because I've seen others make such
statements as well, and all they do is cause further division and
animosity. It shifts debate from the merits of a particular issue or RFC to
more abstract levels, where both sides paint the other in absolute terms
that aren't close to valid.


> To me the "file level" seems most realistic.
> If someone can make a convincing point of what "package level" would
> mean technically, why not.
> I just think that "package" is not a clearly defined term, and often
> all you have is a file (e.g. with symlink, or when downloading a file
> from some place).
> And sometimes you might want different versions / generations in the
> same package.
>

My first reply got rejected by the listserv for being too big. I cleaned up
some the quoted text, but I apologize if anyone sees this twice.

Chase Peeler
chasepeeler@gmail.com

--0000000000004e97a2059159157f--