On Wed, Sep 21, 2016 at 6:13 PM, Nicolas Grekas <nicolas.gre...@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
