Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93938
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.66 as permitted sender)
MIME-Version: 1.0
Reply-To: bishop@php.net
Sender: bishop.bettini@gmail.com
In-Reply-To: <917d2186-e4c2-a2ab-b23b-624cb8973112@gmail.com>
References: <BY2PR0201MB178408B05E7A793C6470C7A9BF5C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <917d2186-e4c2-a2ab-b23b-624cb8973112@gmail.com>
Date: Mon, 13 Jun 2016 10:18:53 -0400
Message-ID: <CAEYWF=7qjdso83v2ABc4j_duYSigp4-S24dK3W93ZoZLAOuWXA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11398e022de59505352993dd
Subject: Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with
 "Too few arguments" exception
From: bishop@php.net (Bishop Bettini)

--001a11398e022de59505352993dd
Content-Type: text/plain; charset=UTF-8

On Mon, Jun 13, 2016 at 9:07 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 06/06/2016 08:22, Dmitry Stogov wrote:
>
>>
>> This mini RFC has been moved to "Voting" state.  Voting
>> began on Jun 6 and will close on June 16.
>>
>> You can find the full RFC at: https://wiki.php.net/rfc/too_few_args
>>
>>
> The more I think about this RFC, the less I agree with it being included
> in 7.1.
>
> I realise this is now officially late in the approval process to raise
> these points, but note that the discussion period was just 5 days, when a
> language change would normally require 2 weeks.
>
> <snip>
>
> There is an assumption from those who have spoken in favour of the RFC
> that such warnings will rarely be ignored in real world code, and therefore
> nobody will actually be affected by this. Here, we are pitching anecdote
> against anecdote; my feeling is that many people routinely ignore warnings,
> and will consider their code to be "running fine" under 7.0, then see it
> "crash" under 7.1.


> I was pleased when the "minor versions will retain BC" policy was adopted,
> because I thought it would avoid the problems we had with PHP 5.3 and 5.4,
> and allow wider adoption of the latest version. Allowing this change would
> mean that promise has been broken.
>

Rowan, spot on. We're breaking promises, *when we don't need to: *just
accelerate releases of major versions.

In my mind, a version makes a concise statement about what changes to
expect. It's like a changelog, but with less reading. But that only works
when the major, minor, and patch numbers have stable meanings.

I would rather see us establish and hold firm on the membership rules (what
kind of change can go in what version) and quickly release queued
implementations, than destabilize the meaning of version numbers.

For example, our promise might read like:

"Patches do not change the language. Minors may *add* non-breaking language
features. Majors may *change* language features. Releases will be made as
soon as there is a critical mass of queued implementations."

What's in a release, when a release goes out, and when it's no longer
maintained is all arbitrary. Amidst all this arbitrariness, let's at least
give our users version numbers with reliable meaning.

bishop

--001a11398e022de59505352993dd--