Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76501
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAF_a60pjwwsUq-rWMOwDoP=B1=tgBZ1w14xPjN1mBSK5HTd+jQ@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>
	<CAF_a60pjwwsUq-rWMOwDoP=B1=tgBZ1w14xPjN1mBSK5HTd+jQ@mail.gmail.com>
Date: Wed, 13 Aug 2014 17:02:22 -0700
Message-ID: <CAKOpQSxAGbeqAsw3sbmGy+3Kzj=W3pk1BOcpN+pfrbvas=uGnQ@mail.gmail.com>
To: Drew Paroski <drewparoski@gmail.com>
Cc: PHP internals <internals@lists.php.net>, 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: multipart/alternative; boundary=089e01160bf8711c6e05008b9e60
Subject: Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single
 switch statement
From: kris.craig@gmail.com (Kris Craig)

--089e01160bf8711c6e05008b9e60
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 13, 2014 at 3:21 PM, Drew Paroski <drewparoski@gmail.com> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I do feel it necessary to point out at this juncture that the last 16 hours
of this thread are EXACTLY why the RFC process requires a minimum of two
weeks of discussion before voting is initiated on language-touching
proposals.  I'll repeat my request that the author either cancel the
premature vote and wait the full two weeks or just cancel the RFC
altogether.  If you don't feel an RFC is necessary, that's fine.  But if
you do post an RFC, please follow the rules.

--Kris

--089e01160bf8711c6e05008b9e60--