Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95451
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAH-PCH6zmgF34oEEXjvkD7k6z79dwLA81=UbjuekT3BNkst+2Q@mail.gmail.com>
References: <CAEbg-4ZAMB=Em-nwCp++K3n59btaFSgW-yexhg3cbM3bQ1WjTg@mail.gmail.com>
 <CAMUwpuQe1bS1D9KVRKkqd7-jXw8sx_mWUDrxDjX=i9J5LQSnwg@mail.gmail.com>
 <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de> <CAH-PCH6zmgF34oEEXjvkD7k6z79dwLA81=UbjuekT3BNkst+2Q@mail.gmail.com>
Date: Thu, 25 Aug 2016 13:48:57 -0600
Message-ID: <CAFMT4NoYz6zFBGhruhWyfg9KMAJWuMCRZCVf1w_-4w1UGju7Bw@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, Julien Pauli <jpauli@php.net>, 
	Alexander Lisachenko <lisachenko.it@gmail.com>, Rowan Collins <rowan.collins@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1
 to be object, string given
From: levim@php.net (Levi Morrison)

On Tue, Aug 23, 2016 at 9:03 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> On Mon, Aug 22, 2016 at 6:30 PM, Christoph M. Becker <cmbecker69@gmx.de>
> wrote:
>
>> On 22.08.2016 at 18:00, Julien Pauli wrote:
>>
>> > I agree this is a BC break and should not stay as-is in source code.
>>
>> I wonder why we have more than 100 lines of "Backward incompatible
>> changes" in the PHP 7.1.0beta3 changelog[1], if BC breaks shouldn't be
>> introduced in a minor release.
>>
>
> That's a bit loaded question, and leads to a broken windows situation, bu=
t
> from my understanding some people read
> https://wiki.php.net/rfc/releaseprocess differently: consider some BC
> breaks simply bug fixes, or think that we shouldn't stick to absolutes bu=
t
> consider BC breaks on a case-by-case basis.
> personally I think tha
>
>
>>
>> > It makes some testsuites fail, that did not fail before ; thus it brea=
ks
>> things.
>>
>> An estimated 10% (at least) of my *bugfixes* in GD broke at least one
>> PHPT, because the test was broken in the first place.
>>
>
> test failures can be false positive or depending explicitly undefined
> behaviors, but they can be a good indicator when looking for BC breaks.
> as we can see from the previous mails in this thread there are behavior
> changes where the previous behavior was different from what was documente=
d
> so a bit of a grey area.
>
> personally I think that we are in general too lenient with allowing BC
> breaks in 7.1 (even though that I somehow expected this and was arguing f=
or
> a longer release cycle for 7.0 or at least having a clear roadmap for the
> next major version) and we should be more strict about it otherwise we wi=
ll
> lose the trust we gained from the userland in the last couple of years wi=
th
> our release process and versioning.
>
>
>
> --
> Ferenc Kov=C3=A1cs
> @Tyr43l - http://tyrael.hu

I agree. However in this particular instance emitting an E_DEPRECATED
like I proposed should be helpful. These people who are passing
strings are not getting any behavior out of it - its' completely
ignored. Additionally since its an E_DEPRECATED it's highly unlikely
to actually break something. What do you think?