Newsgroups: php.internals,php.standards
Path: news.php.net
Xref: news.php.net php.internals:76403 php.standards:361
Return-Path: <tyra3l@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 6554 invoked from network); 6 Aug 2014 19:31:39 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 6 Aug 2014 19:31:39 -0000
Authentication-Results: pb1.pair.com smtp.mail=tyra3l@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=tyra3l@gmail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.47 as permitted sender)
X-PHP-List-Original-Sender: tyra3l@gmail.com
X-Host-Fingerprint: 209.85.192.47 mail-qg0-f47.google.com  
Received: from [209.85.192.47] ([209.85.192.47:43962] helo=mail-qg0-f47.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 47/A0-00245-89282E35 for <standards@lists.php.net>; Wed, 06 Aug 2014 15:31:36 -0400
Received: by mail-qg0-f47.google.com with SMTP id i50so3223812qgf.6
        for <multiple recipients>; Wed, 06 Aug 2014 12:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=GG944rhwgx2I63GorqUQSjN/7PwUcf2OZ22Y4bkEaTk=;
        b=DeTfgsEfRjw3zLOIq+IkBdIH2afMUQRKH1O3QkkgCjMcQG+jxZCOTN84xVZ7jFs7Ri
         7pFFE9SPC/QnDN6iPv5hQKrDN8FuapRN5c46Xxq7e6mpNmAr0qkn9CUlFDSlbpomdWug
         OMGI5IFZVfFIfPKjQDpsrjt+d/T8/8iaOLMo+m25rSiglpajyOS4sflc6bx3RwiaXwru
         22UMyhE5vays0zQnGjNT/DYZwDlE4fDBv2uhDN+WE1QYK2tq1XGOOqGhPRScycQSGfd7
         IrC46Uhea3/0M4hQYyDbUeu+16dZNgp17ckK53PPvTI+Kw3Mfe2PlaNoZqSXLxL2MjM+
         c1ZQ==
MIME-Version: 1.0
X-Received: by 10.224.96.137 with SMTP id h9mr20414773qan.96.1407353524637;
 Wed, 06 Aug 2014 12:32:04 -0700 (PDT)
Received: by 10.140.102.111 with HTTP; Wed, 6 Aug 2014 12:32:04 -0700 (PDT)
In-Reply-To: <CAESVnVq0Y2dgSQzpTdt1L5tyWRM_rxVhajujOatWyrH2u_j=5Q@mail.gmail.com>
References: <CAESVnVr0J5qyAc-L0Yt_3Ahab5LVgtUErgoKsSPvgwe=QzppTw@mail.gmail.com>
	<CAH-PCH4bRSGrgicicxtNcQVUBM3gW-TBP1_3RVukw-0=TUpc3A@mail.gmail.com>
	<CAESVnVq0Y2dgSQzpTdt1L5tyWRM_rxVhajujOatWyrH2u_j=5Q@mail.gmail.com>
Date: Wed, 6 Aug 2014 21:32:04 +0200
Message-ID: <CAH-PCH5RqGsQ2T=fmEgnSKOBn_0h4O2EEThvzpVhZq0a_+n_iA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>, standards@lists.php.net
Content-Type: multipart/alternative; boundary=001a11c2e0a8e92ecf04fffb0636
Subject: Re: [PHP-DEV] [RFC] Disallow multiple default blocks in a single
 switch statement
From: tyra3l@gmail.com (Ferenc Kovacs)

--001a11c2e0a8e92ecf04fffb0636
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 6, 2014 at 8:35 PM, Sara Golemon <pollita@php.net> wrote:

> On Wed, Aug 6, 2014 at 3:00 AM, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> > I think dropping this behavior is a good idea, but I'm confused by the
> > reasoning related to the langspec.
> > This rfc targets php.next (which is a safe move as this has BC break
> albeit
> > would require some questionable code), but the langspec was agreed to b=
e
> > based on 5.6 and document how that works.
> >
> Did we agree on that?  The lang spec was originally written to 5.6 to
> have a relatively stable target, but (in my mind at least) was meant
> to track master as we move the language forward.  Was there a
> discussion about branching the langspec repo for versions?


maybe that was just my impression.
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.
would be nice checking out how other spec-driven languages manage this
problem (I know that at least java has separate spec for each major
version), but I don't think that a single spec can exists which allows
alternative implementations to say that they comform me spec while the
reference implementation and the spec can still change/evolve after the
initial release.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--001a11c2e0a8e92ecf04fffb0636--