Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96066
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.172 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 18:19:41 +0200
Message-ID: <CAF+90c_w_m9bkDZvR9CwCH4=nSf8LVdHUSa=ThnZ2J6Y4QijpA@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0bcc20a3a920053d06e9a6
Subject: Re: [PHP-DEV] Fix ReflectionType::__toString() BC break
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c0bcc20a3a920053d06e9a6
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 21, 2016 at 6:13 PM, 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 :)
>
> Nicolas
>

Thank you for quoting a single sentence out of a larger mail and completely
ignoring the rest :/

I don't insist on keeping the current behavior. I'm just saying that if we
don't keep it, we should also deprecate the method. This is both
backwards-compatible (per the usual interpretation that a deprecation is
not a BC break) and ensures that "everybody not following internals to
adapt to latest BC breaks" is still made aware that they should change
their code to use the getName() API in 7.1 to avoid future problems of this
kind.

Nikita

--94eb2c0bcc20a3a920053d06e9a6--