Re: BC break: ReflectionMethod::invoke() expects parameter1 to be object, string given
| From: | Rowan Collins | Date: | Mon, 22 Aug 2016 18:34:14 +0000 |
| Subject: | Re: BC break: ReflectionMethod::invoke() expects parameter1 to be object, string given | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95389@lists.php.net to get a copy of this message | ||
On 22/08/2016 17:30, Christoph M. Becker wrote:
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]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.