Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71887
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <1d5850561e0ef9e7739c7e7b7b0448d0.squirrel@webmail.klapt.com>
In-Reply-To: <52EAF0A3.2000001@oracle.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
    <52EAF0A3.2000001@oracle.com>
Date: Fri, 31 Jan 2014 21:26:34 +0100
To: "Christopher Jones" <christopher.jones@oracle.com>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: anatol.php@belski.net ("Anatol Belski")

Hi Chris,

On Fri, January 31, 2014 01:38, Christopher Jones wrote:
>

>
> On 01/27/2014 12:15 PM, Anatol Belski wrote:
>
>> https://wiki.php.net/rfc/size_t_and_int64
>>
>>
>> There was two big questions regarding the compatibility. Those open
>> questions appeared in the discussions are reflected in the reworked RFC.
>>
>>
>> First question, the possibility to keep the old zend_parse_parameters()
>>  specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping
>> the old zpp specs will for sure minimize the porting effort for the PECL
>>  extensions, but might lead to confusion (like people might think ‘l’
>> still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3
>> to decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.
>>
>> Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
>>  The reason for such renamings was to ensure source level
>> incompatibility on compile time. However this might have a negative
>> effect on the porting effort (despite the porting tools). Please use the
>> yes/no Vote 2 to decide whether the old macro names have to be kept.
>>
>> The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
>> merely to decide about the semantical replacements choosen for the
>> patch. Should the Votes 2 and 3 result in reverting of that semantical
>> changes, the essential patch part about the 64 bit support will not be
>> hurt. Reverting to old macro names or zpp specs is only the naming
>> issue.
>>
>> Removal of the dead SAPIs is isolated in a separate RFC and can be
>> considered to another time.
>>
>> Thanks for the constructive discussions on this RFC, support and
>> testing. The vote begins Monday, 27 January 2014, 21:30 CET and ends
>> Monday, 03
>> February 2014, 21:30 CET.
>>
>>
>>
>
> Hi Anatol,
>
>
> A quick question: am I right to assume that because this vote has
> widespread impact on PHP it needs 2/3 majority per
> https://wiki.php.net/rfc/voting ?
>
>
> It's not totally clear that the change is covered by any of the examples
> in the voting RFC, but I see the 64 bit project as affecting the language
> as a whole (for better or worse!)
>
catching up on this now as this was delayed by the mail issues.

I'm not a native speaker, however what i read here

[QUOTE]
We also need to ensure, as much as possible, that the decision isn't based
on some arbitrary circumstances (such as a temporary marginal majority for
a certain school of thought). For these reasons, a feature affecting the
language itself (new syntax for example) will be considered as 'accepted'
if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get
'accepted'.
[/QUOTE]

sounds for 50%+1, as it affects not the language itself (no syntax
changes, etc.) but its implementation. Even in such an unusual case :)

Regards

Anatol