Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74165
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 209.85.128.178 cause and error)
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>
In-Reply-To: <CAH-PCH7mQkdV=JM0R4zF5-rwMLDmZCrWWqidhZG6TcVdyffgow@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQC7HuE3UTXSihebCHoftrMU80C7TANQnU43APB9DS4CfHO5+wLX3e4wAqgCypudBnM60A==
Date: Wed, 14 May 2014 01:31:33 -0700
Message-ID: <6853924b0c5b1d21104925fe72898d68@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0115f0a228001e04f9580267
Subject: RE: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string
 length and integer
From: zeev@zend.com (Zeev Suraski)

--089e0115f0a228001e04f9580267
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I agree, and I=E2=80=99m not suggesting we ignore it;  I just pointed out i=
t makes
no sense that such a drastic low-level change will be forced on those who
effectively maintain the low-level engine for all of us.  I don=E2=80=99t h=
ave a
magical solution on how to solve it at this point.



I did suggest two solutions to the situations within the current voting
process:



1.      Clearly expressing the concerns Dmitry has about this patch in the
Performance section, so that at least people know what=E2=80=99s on the tab=
le;  And
add another option =E2=80=93 the option =E2=80=93 the one that has the true=
 userland
implications (the parts related to IS_LONG), and mention clearly that this
one will come with no meaningful performance (memory/CPU) drawbacks.

2.      If the authors of the RFC object (which is within their right, of
course) =E2=80=93 appealing to voters to vote =E2=80=98no=E2=80=99 on this =
one, and create another
RFC for the IS_LONG parts.



Zeev



Even though that I agree, that our current voting process is suboptimal,
but I would rather see it fixed instead of ignoring the rules when it is
inconvenient/plain wrong.

What I do think is wrong with the current rfc, is that it states that it
needs only 50%+1 of the votes for acceptance.

The patch is big, it will affect every php installation (eg. not just some
platforms), it changes the Zend Engine, and it requires some non-trivial
effort from the extensions to support it, so even though that the direct
impact on the userland isn't that big (code with long strings etc. which
would fatal will now starts working, big numbers will overflow differently,
etc.) I think it still mandates a 66%+1 vote.



Just my 2 cents.



--=20

Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e0115f0a228001e04f9580267--