Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96105 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98625 invoked from network); 23 Sep 2016 05:38:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Sep 2016 05:38:14 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.181 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.217.181 mail-ua0-f181.google.com Received: from [209.85.217.181] ([209.85.217.181:33004] helo=mail-ua0-f181.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 70/E4-59356-5CFB4E75 for ; Fri, 23 Sep 2016 01:38:14 -0400 Received: by mail-ua0-f181.google.com with SMTP id u68so24888533uau.0 for ; Thu, 22 Sep 2016 22:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cmf0Zj1+qDZ4zXFhmGMltgt1LVXBOgZy4c8amCLOGfg=; b=j3v94m1nqTYOtqAYzjzRL/uaZIp03BWNhnblMcnP/ohdl9WZcVs7ljs8lUfsP9U7Av Q1Mk9sj7D6JXlBOFtu7cZ9zMv476l2R+pKzGmw3BQksKeeUtMoeAfPyA7be/SYo2Bjt6 xJjhEX480uRN0lPkfyeBkJOKs9NRDn5pJMuBjuSKMOQiCocIVgyl/dKgIsQ/G0Paurzm cJcHSsEZozPAxzstwCjA+H/ZpfZVMw2LvbC3of6DbNImH8Ia304ZFCg6YGUcIdEH1lY2 Ku2oYwMnA3wmDN9Hs/8WX2UGroHgzopKFwJPJRXWXE7IzZmqAPTZqMAVR+sTqPO2Fc2l hGkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cmf0Zj1+qDZ4zXFhmGMltgt1LVXBOgZy4c8amCLOGfg=; b=HhSMzS9Z2TWwP1GLgUAQYkIutKAgH8gvZMyT6CvutezOsw56n778OnwmS0vG/f1OWK dLUNnS/PnEoYNkMaYav6bIG+Q5PXZ2+pWLoNMlGZH50zFkEOOMOCl0k3cUWjStCbqGJg VvjobGW6VE9YvX5EpHz7sGm4MNG08gfGP8CFgJhl4kCdDCFs3T36rPIrZvDKnvqwSuv3 aLwvixN+65ShdP7X66IbLEfv7UOY/M6hRNiL6fH65g4Ka2+DI0gldm+0UZxN+u5jOL0h 0bBIOn/hu/Wb288xG2Zsw3ratpplvdm1p59HCP1GZXNCyQh/rBmYQBoHkI4hy6EdIrzG DcOQ== X-Gm-Message-State: AA6/9RkIuZqo4lKY36mtAx+Tb4sJ1bRLNavEIwE/+vkq3Q5xnvdB36BBqhsk/RkML9P9apot72Bs2OQUkQwVUw== X-Received: by 10.176.3.172 with SMTP id 41mr2580109uau.159.1474609090566; Thu, 22 Sep 2016 22:38:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.81.178 with HTTP; Thu, 22 Sep 2016 22:38:07 -0700 (PDT) Received: by 10.176.81.178 with HTTP; Thu, 22 Sep 2016 22:38:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Sep 2016 12:38:07 +0700 Message-ID: To: Levi Morrison , Davey Shafik Cc: Nicolas Grekas , Ryan Pallas , PHP internals Content-Type: multipart/alternative; boundary=94eb2c000bd806a119053d262f77 Subject: Re: [PHP-DEV] Fix ReflectionType::__toString() BC break From: pierre.php@gmail.com (Pierre Joye) --94eb2c000bd806a119053d262f77 Content-Type: text/plain; charset=UTF-8 Adding the RMs. Dacey, I think this needs a deeper look and decision. On Sep 22, 2016 7:51 AM, "Pierre Joye" wrote: > > On Sep 22, 2016 1:07 AM, "Levi Morrison" wrote: > > > > On Wed, Sep 21, 2016 at 11:13 AM, Nicolas Grekas > > 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, > > Which does not allow BC breaks but for extreme cases. I do not consider this case as extreme, at all. > > I share Nicolas concerns here. This is the kind of changes making the migration path harder than it should without a strong reason behind it. > > I agree with Nikita but it is something that can be solved using the depreciation flag and then handle in the next major. > > > 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? > > Obviously the sooner. And what is the next BC breaks for 7.2/3/4? > > This is exactly why we introduce the no BC break rule. > > In this case it is even more clear as one can use getName if desired to support 7.1+ only, which I suppose is most likely not the case for a large majority of users. --94eb2c000bd806a119053d262f77--