Re: ReflectionType::__toString() prepending \ to class names

From: 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/

« previous php.internals (#95352) next »