Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95452
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.52 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAFMT4NoYz6zFBGhruhWyfg9KMAJWuMCRZCVf1w_-4w1UGju7Bw@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>
 <CAFMT4NoYz6zFBGhruhWyfg9KMAJWuMCRZCVf1w_-4w1UGju7Bw@mail.gmail.com>
Date: Fri, 26 Aug 2016 11:14:41 +0200
Message-ID: <CAMUwpuQLdmiZD-44K3X+a-z0+bbGaD6U8XAbXKY6ug7NNHtSwg@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	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: jpauli@php.net (Julien Pauli)

On Thu, Aug 25, 2016 at 9:48 PM, Levi Morrison <levim@php.net> wrote:
> 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, b=
ut
>> 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 b=
ut
>> 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 bre=
aks
>>> 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 document=
ed
>> 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 =
for
>> a longer release cycle for 7.0 or at least having a clear roadmap for th=
e
>> next major version) and we should be more strict about it otherwise we w=
ill
>> lose the trust we gained from the userland in the last couple of years w=
ith
>> 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?

I'm OK to generate a E_DEPRECATED and continue ignoring the first parameter=
.

And then talk about ways to call parents in child context as ideas,
debates, RFCs and patches.
I myself can work on patches, but as usual, not on ideas as I can't
get the point for such use cases.


Julien