Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71889
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain oracle.com designates 141.146.126.69 as permitted sender)
Message-ID: <52EC0B34.8080109@oracle.com>
Date: Fri, 31 Jan 2014 12:44:36 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Anatol Belski <anatol.php@belski.net>
CC: PHP Developers Mailing List <internals@lists.php.net>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>    <52EAF0A3.2000001@oracle.com> <1d5850561e0ef9e7739c7e7b7b0448d0.squirrel@webmail.klapt.com>
In-Reply-To: <1d5850561e0ef9e7739c7e7b7b0448d0.squirrel@webmail.klapt.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: christopher.jones@oracle.com (Christopher Jones)



On 01/31/2014 12:26 PM, Anatol Belski wrote:
> 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
>

The voting RFC's use of "for example" indicates that syntax changes are
just one part of "feature[s] affecting the language".

I agree that the 64-bit RFC doesn't affect syntax.  However it does
materially affect the language, so I believe it requires a 2/3
majority.

Chris

PS It's a pain to be micro-analyzing like this, but that's what the
PHP community got when it decided to formalize the feature adoption
process.


-- 
christopher.jones@oracle.com  http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html