Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95386
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.47 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@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 18:34:20 +0200
Message-ID: <CAMUwpuSMq-r7t3e7s6SzAQ4_NhL4gV=Hd-UwdSu1ET1M8aQesA@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: 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
Subject: Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1
 to be object, string given
From: jpauli@php.net (Julien Pauli)

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.
>
>> 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.

Well, we must find a solution that tries to cope with everyone needs,
and tries to make PHP more consistent if possible.

I know it is not an easy topic , but I'm sure we'll find some consensus.

I'll prepare a patch exposing my ideas soon.



Julien