Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74186
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <B95C868D-E2E2-4E7C-8830-30CC7CB55CBD@ajf.me>
References: <e5f19ac0089d24adc695fce93ad9bd9c.squirrel@webmail.klapt.com>
	<CA+9eiLuoJM5bwA46M_2YddTXYOhAwhii=9Ref7-NNeuRuBfW5A@mail.gmail.com>
	<CAEZPtU7zz=npjUhacwSBA6cz+kb9iBmn3fjkvYuAjqtiPQgJhw@mail.gmail.com>
	<CAF+90c9J5mtTzqFxvQHka5w5zVoGOzXNaUeYec62X_LYLOPcxA@mail.gmail.com>
	<db6f4b4c2d10f343d4c30ee66d82b0eb@mail.gmail.com>
	<CAH-PCH7mQkdV=JM0R4zF5-rwMLDmZCrWWqidhZG6TcVdyffgow@mail.gmail.com>
	<CAKOpQSwVOzkza9oy9EBWc+iqfabX7Un+kFxyYMwORpxNgTQsrg@mail.gmail.com>
	<9EBA64F4-9A75-4DD1-9DB3-17F78B329BE7@ajf.me>
	<CAKOpQSy0XX1NMSFrUZyrqt18+Am000qGLCuMK8YQQ_wany0T_Q@mail.gmail.com>
	<CAKOpQSynX8tah+swpKGpCC+GMGoO1uJeDj7sgjMfaS4rsWvNqQ@mail.gmail.com>
	<B95C868D-E2E2-4E7C-8830-30CC7CB55CBD@ajf.me>
Date: Wed, 14 May 2014 03:02:29 -0700
Message-ID: <CAKOpQSxtORXfVtmCUSubGRr69SX-48pvtgWxDCoNpOi5F-KsXA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Ferenc Kovacs <tyra3l@gmail.com>, Zeev Suraski <zeev@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1139bb884015c804f959477c
Subject: Re: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: kris.craig@gmail.com (Kris Craig)

--001a1139bb884015c804f959477c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2014 at 2:49 AM, Andrea Faulds <ajf@ajf.me> wrote:

>
> On 14 May 2014, at 10:47, Kris Craig <kris.craig@gmail.com> wrote:
>
> Just a quick reminder, here's the document outlining the RFC voting
> process:
>
> https://wiki.php.net/rfc/voting
>
>
> While I don=E2=80=99t really disagree with 2/3 here, going by that RFC, i=
sn=E2=80=99t this
> a 50%+1 non-language change?
>

Technically, I think it could probably be interpreted either way, depending
on how broadly you define "language change".  Though the underlying syntax
of PHP isn't being altered, there are several macro renamings and numerous
other across-the-board changes.  I think a reasonable argument could be
made that anything with this large of a scope could be defined as a
fundamental language change.  I can't help but note that the voting RFC
mentions, "new syntax for example", the latter "for example" part seemingly
an acknowledgement that a language change is not limited solely to
syntactic alterations to the underlying grammar.

But again, I think a reasonable person could interpret the rule's language
either way.  I would recommend that we update that RFC in the near future
to provide more specificity to account for otherwise subjective situations
like this.  In the meantime, I suppose the decision is left to the RFC's
author, Anatol.  If nothing else, I think it would be wise from a political
standpoint to err on the side of the higher requirement.  Hopefully this
will get enough votes so the requirement will end-up being a moot point,
anyway.

--Kris

--001a1139bb884015c804f959477c--