Re: BC break: ReflectionMethod::invoke() expects parameter1 to be object, string given

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, but >> 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 but >> 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 breaks >>> 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 documented >> 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 the >> next major version) and we should be more strict about it otherwise we will >> lose the trust we gained from the userland in the last couple of years with >> our release process and versioning. >> >> >> >> -- >> Ferenc Kovács >> @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