On Wed, Sep 21, 2016 at 7:51 PM, Ryan Pallas <derokor...@gmail.com> wrote:
> > > On Wed, Sep 21, 2016 at 12:44 PM, Jakub Zelenka <bu...@php.net> wrote: > >> Hi, >> >> On Wed, Sep 21, 2016 at 7:07 PM, Levi Morrison <le...@php.net> wrote: >> >>> On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas >>> <nicolas.gre...@gmail.com> wrote: >>> >> To handle this in code written around current __toString seems pretty >>> > simple >>> > >>> > Yes it is, but that's not what we're talking about: >>> > BC is about having perfectly fine code working in e.g. 7.0 be still >>> working >>> > fine on 7.1 *without any change*. >>> > >>> > Right now, we have red test suites on php7.1rc2. >>> > This is the symptom of a BC break, by definition. >>> > And the issue is not the existing code we have, but the new one that is >>> > changing the behavior of the engine. >>> >>> This was understood when the decision was made. You seem to not be >>> understanding the bigger issue and instead focusing on the BC break >>> for a *single minor release, and a dot zero at that*. If we keep the >>> BC compat this method is redundant and useless forever. If we fix it >>> we break your code for *one single minor release, and a dot zero at >>> that*. Which is the bigger disruption? >>> >>> This is why the decision was made. It is better to have the useful >>> functionality from here on out than to preserve BC with a single minor >>> release, and a dot-zero at that. >>> >>> >> I'm just wondering, how is it possible that this got changed when the >> only RFC mentioning this change got rejected ( >> https://wiki.php.net/rfc/reflectiontypeimprovements )? I don't see any >> consensus in the later discussion so unless I missed something, which is >> quite possible, this change should not be there in the first place, right? >> > > The best I can find are these messages [1] where it specifically mentions > that toString should change even though this was rejected, and it had at > least some agreement at the time. > > [1] http://php-news.ctrl-f5.net/message/php.internals/94452 > >> >> Yeah my bad, missed that one! Thanks
