Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95389
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.49 as permitted sender)
To: PHP Internals <internals@lists.php.net>
References: <CAEbg-4ZAMB=Em-nwCp++K3n59btaFSgW-yexhg3cbM3bQ1WjTg@mail.gmail.com>
 <CAMUwpuQe1bS1D9KVRKkqd7-jXw8sx_mWUDrxDjX=i9J5LQSnwg@mail.gmail.com>
 <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de>
Message-ID: <c6bc9321-1525-94e8-15e6-70400ad1cdfd@gmail.com>
Date: Mon, 22 Aug 2016 19:34:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <dd455ef8-d02f-9e7f-94ba-8e276bce2688@gmx.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] BC break: ReflectionMethod::invoke() expects parameter1
 to be object, string given
From: rowan.collins@gmail.com (Rowan Collins)

On 22/08/2016 17:30, Christoph M. Becker wrote:
>> 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.

Yeah, that was basically my concern as well: giving the string parameter 
a meaning is no more compatible than rejecting it. It is, at least, more 
*useful*, but it does make the same code do subtly different things in 
the new version.

One question which would need addressing is what should happen if you 
reflect a static method call, and pass in an object as the invocation 
context:

- As currently, even with the patch that's in beta, ignore the object 
completely? (This seems broken to me.)
- Reject it outright, saying that it must be a string or null? (Simple, 
but not very user-friendly.)
- Verify that it's of the right type (as with a non-static invocation), 
then take its class as the context of the call? (Seems best, but 
possibly complex?)

Altogether, I think this may need more thought than a rushed fix during 
a beta cycle. How about reverting the behaviour for 7.1 and changing 
carefully in 7.2?

Regards,

-- 
Rowan Collins
[IMSoP]