Re: ReflectionType::__toString() prepending \ to class names
| From: | Marco Pivetta | Date: | Sun, 21 Aug 2016 19:43:25 +0000 |
| Subject: | Re: ReflectionType::__toString() prepending \ to class names | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95352@lists.php.net to get a copy of this message | ||
Hi Dan,
On Sun, Aug 21, 2016 at 8:55 PM, Dan Ackroyd <danack@basereality.com> wrote:
> On 21 August 2016 at 17:01, Marco Pivetta <ocramius@gmail.com> wrote:
> > Yes, but the __toString API is used for codegen, and current code
> > generators don't expect a
? to appear there.
>
> And they will continue to not have a ? when reflecting PHP 7.0
> code.
>
Sadly, it won't. Here's an example that shows the BC break in a more
explicit way:
function foo(Iterator $i = null) {}
var_dump((string) (new ReflectionParameter('foo', 0))->getType());
This reports Iterator for PHP 7.0.x, ?\Iterator for 7.1.x.
https://3v4l.org/tDkLj
> It is only when reflecting 7.1 code, that has a different set of
> syntax, that the library will need to be changed to support a new
> version of PHP code.
>
Same as above. The problem is on existing code.
> This is exactly the same as userland PHP code parsers. They continue
> to work in new versions of PHP, but only when analysing code from
> versions they were written to support. They will need to be upgraded
> to be able to parse syntax that wasn't present in the version of PHP
> that they were initially written for.
>
> > How many ... failing unit tests does it take to explain a BC break?
>
> As nullable types are only introduced in PHP 7.1, I strongly suspect
> that you won't have any unit tests that would work on PHP 7.0 that
> will start failing on PHP 7.1.
>
> So the answer is 'more than zero' ?
>
The answer is "one that at least ran the frikken tests".
> We don't consider adding new features to be a BC break, as any code
> analyser or thing that uses reflection will continue to work, when
> they are given code from a version they were designed to support.
>
New features: OK. We all agree that void and ?Foo need adaptations in
userland libs.
I wrote it before, and specifically wrote "New features => new
codegen/changes, this is normal/understood/accepted."
The issue here is around changes that affect old features (__toString),
where the behavior changes depending on whether a parameter is defaulted or
not (also a previously existing feature)
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/