Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96065
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF+90c9XW7G-7CtKCWt+JOm5vE1XTnC92AkHvmBe9fohTOWeKA@mail.gmail.com>
References: <CAOWwgpn1_ZHxQq9FpiwCYoqT3kVHH0k3LgO7E+eX5N2ybjDtrg@mail.gmail.com>
 <CAF+90c9XW7G-7CtKCWt+JOm5vE1XTnC92AkHvmBe9fohTOWeKA@mail.gmail.com>
Date: Wed, 21 Sep 2016 18:13:09 +0200
Message-ID: <CAOWwgpm6YL+kiwT=n8QdeKHVYg=KG7aCp=2Cv5qn0nRVNwR0bA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b8750cc70de4d053d06d34a
Subject: Re: [PHP-DEV] Fix ReflectionType::__toString() BC break
From: nicolas.grekas@gmail.com (Nicolas Grekas)

--047d7b8750cc70de4d053d06d34a
Content-Type: text/plain; charset=UTF-8

>
> 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 :)

Nicolas

--047d7b8750cc70de4d053d06d34a--