Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95390
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.54 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de>
References: <CAEbg-4ZAMB=Em-nwCp++K3n59btaFSgW-yexhg3cbM3bQ1WjTg@mail.gmail.com>
 <CAMUwpuQe1bS1D9KVRKkqd7-jXw8sx_mWUDrxDjX=i9J5LQSnwg@mail.gmail.com> <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de>
Date: Mon, 22 Aug 2016 13:57:51 -0600
Message-ID: <CAFMT4Noh_2BHDUETFtUppJi36m4vuYtmU1A2h_t-Swha1sxKdQ@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: 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: multipart/alternative; boundary=001a1136c052a922b4053aae7651
Subject: Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1
 to be object, string given
From: levim@php.net (Levi Morrison)

--001a1136c052a922b4053aae7651
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 22, 2016 at 10:30 AM, 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.
>
> > 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.
>
> > I think @Alexander is right.
> > We should allow passing a string, and perform some Late Static Binding
> > through it.
> > That would solve the BC Break problem as well as extend the feature in
> > a more PHP-friendly way.
>
> Are you sure that would solve the BC break?  As it were, one could pass
> an arbitrary string.  I can easily imagine that some refactoring
> introduced a new class in a hierarchy, but nobody noticed that an
> ::invoke() call would have to be adjusted accordingly.  Suddenly
> changing the meaning of the first parameter may well introduce a
> behavioral change.
>
> [1] <https://github.com/php/php-src/blob/PHP-7.1.0beta3/UPGRADING#L18-L129
> >


I was a little unclear in the beginning, so let me clear something up now:
if it's not documented how can anyone be sure what the correct behavior is?
Attempting to preserve backwards compatibility on something undefined is
meaningless.

Now if something was simply not documented that's a bit different. I think
the ideal but difficult path forward is to find where it was introduced and
pray the commit log or something else will indicate the behavior. Only then
can we properly preserve it. Until then it is undefined behavior that I
don't care one whit about. And attempting to "improve it" by adding late
static binding somehow would also be pointless until the original behavior
is identified.

As it stands I am fine to keep the BC break or revert it - doesn't really
matter. But if anyone *does* care then they need to do some digging.

--001a1136c052a922b4053aae7651--