Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96067
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOWwgpm6YL+kiwT=n8QdeKHVYg=KG7aCp=2Cv5qn0nRVNwR0bA@mail.gmail.com>
References: <CAOWwgpn1_ZHxQq9FpiwCYoqT3kVHH0k3LgO7E+eX5N2ybjDtrg@mail.gmail.com>
 <CAF+90c9XW7G-7CtKCWt+JOm5vE1XTnC92AkHvmBe9fohTOWeKA@mail.gmail.com> <CAOWwgpm6YL+kiwT=n8QdeKHVYg=KG7aCp=2Cv5qn0nRVNwR0bA@mail.gmail.com>
Date: Wed, 21 Sep 2016 10:30:10 -0600
Message-ID: <CAObuZduNr1oKRx0MKdGG=9XLADZF_tP4YORTk486kWa6CC_=Hg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122af342142ce053d070f28
Subject: Re: [PHP-DEV] Fix ReflectionType::__toString() BC break
From: derokorian@gmail.com (Ryan Pallas)

--089e0122af342142ce053d070f28
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 21, 2016 at 10:13 AM, Nicolas Grekas <nicolas.grekas@gmail.com>
wrote:

> >
> > See https://github.com/php/php-src/pull/2136
> >>
> >
> > I don't like this.
> >
>
> I understand, really. I do have to deal with BC on Symfony side also and
> it's a really hard constraint. Yet, we stick to it as much as possible, in
> order to not add pain to others.
> Sometime, we have to be pragmatic and accept solutions that are not "pure",
> for the shake of our BC promise.
>
> PHP internals has such a BC policy, it should really stick to it. It's not
> always fun, for sure, but the pain for others it strong. It's not only
> me&Ocramius, nor Symfony&Zend: everybody not following internals to adapt
> to latest BC breaks will be hit, potentially. This is bad for the
> reputation of PHP. It makes the PHP platform unstable as far as confidence
> is concerned.
>
> In this case, we should find a technical solution that preserves BC. Being
> this patch or unconditionally returning the type name with nullable info is
> fine, you'll decide what's best.
>
> But please don't consider BC as something that one can bypass when it gets
> annoying.
>
> Thanks from me and from many others for considering :)
>

I'm not so sure its a BC though. Technically nullable types don't exist in
7.0 and as such would be impossible to return said question mark. Its only
adding support for a new feature, not changing how an existing feature
works IMO. If nullable types had been in 7.0 its highly probably, that
__toString would have returned the leading question mark back then.


> Nicolas
>

--089e0122af342142ce053d070f28--