Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76500
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAJF_ukVFt5W3=MMnOXe+LWVv-9k_WpNdn6GsAb4-7AOYJEiwwg@mail.gmail.com>
References: <CAESVnVr0J5qyAc-L0Yt_3Ahab5LVgtUErgoKsSPvgwe=QzppTw@mail.gmail.com>
	<CAH-PCH4t1bnGwOmitU4cS4W--==8sZRhw1X-DkV0Y7zNj8E3kw@mail.gmail.com>
	<942D2AF6-BDC2-4214-BD58-4B5945C28CE3@ajf.me>
	<CAEZPtU4k95KFAs0sf04KK6ASJz_U0Zk7jTTAVcrwMO7MTnouPg@mail.gmail.com>
	<B83858AC-CE12-4F90-9F7C-71EAD69DD6AD@ajf.me>
	<CAPg3XxLsdb8gZPOkhOmQcdpfx_b7d-jK1r6Fn9Fmki1yCmaz6g@mail.gmail.com>
	<CAJF_ukVFt5W3=MMnOXe+LWVv-9k_WpNdn6GsAb4-7AOYJEiwwg@mail.gmail.com>
Date: Wed, 13 Aug 2014 15:21:36 -0700
Message-ID: <CAF_a60pjwwsUq-rWMOwDoP=B1=tgBZ1w14xPjN1mBSK5HTd+jQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Cc: Peter Cowburn <petercowburn@gmail.com>, Andrea Faulds <ajf@ajf.me>, 
	Pierre Joye <pierre.php@gmail.com>, Ferenc Kovacs <tyra3l@gmail.com>, James <james@notjam.es>, 
	Matthew Fonda <matthewfonda@gmail.com>, Sara Golemon <pollita@php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single
 switch statement
From: drewparoski@gmail.com (Drew Paroski)

On 6 August 2014 12:32, Ferenc Kovacs <tyra3l@gmail.com> wrote:
>
> I'm not sure what would be the best solution, but if we don't version the
> spec, then when we introduce BC breaks or simply new features in a new
> version which is in turn get's added to the spec, that would make the older
> php version's(from any implementation) not being compliant with the spec.

I agree with Andrea that this fix/change is arguably not a BC break. For
something where there is broad consensus that it's a bug (or at the very least
highly undesirable behavior) and the fix has very low risk of breaking existing
programs, it seems poor to update the spec to codify the bug. While the goal of
the spec is to describe PHP 5.6's current behavior as it is, I think it should
stop short of requiring that conforming implementations mimic existing bugs in
php.net PHP 5.6.

Making the spec codify bugs is bad for two reasons. First, it encourages other
implementations to mimic bugs causing these bugs to propagate further and
making them harder to ultimately fix. Second, it makes the spec more
complicated and more difficult to maintain without delivering any real value.
It's okay if php.net PHP is not 100% spec compliant as long as the all the
differences are considered bugs.

Going the RFC route for this issue felt a bit a like overkill to me, but I
respect the process :). The spirited discussion here was interesting to read
and informative. I don't have strong feelings about what version of php.net PHP
the fix should be applied to, or whether it should be allowed but E_DEPRECATED
for a period of time, but IMHO getting the fix in sooner rather than later
feels like the right way to go.

For future cases like this that are initially filed as bugs, I think discussion
should first focus exhaustively on determining whether or not the issue is a
bug before moving on to discussing whether the spec should be changed. I think
this will help reduce churn on the spec and will keep things simpler and more
light-weight for most cases like this.

-Drew

On Wed, Aug 13, 2014 at 9:22 AM, Matthew Fonda <matthewfonda@gmail.com> wrote:
> On Wed, Aug 13, 2014 at 3:24 AM, Peter Cowburn <petercowburn@gmail.com>
> wrote:
>>
>> My thoughts on the topic? I think we're in danger of letting "process" get
>> in our way here. It's a bug fix which IMHO should even be thrown into 5.6
>>  (this is a bug fix!). Going through the RFC process, being forced to wait
>> for 5.7 or 7, extended discussions on the list... it all just seems
>> unnecessary. But, that's just the opinion of a docs guy. :-)
>
>
> +1, my thoughts as well.
>
> Best regards,
> --Matt