Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71701
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: <52E8198E.6080202@oracle.com>
Date: Tue, 28 Jan 2014 12:56:46 -0800
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>	<CAF+90c-W+un8BsBD3OAeVL05s3iM5RxGnOD2Xa7nBPC+TuPijg@mail.gmail.com> <CAEp07h-NZpJ9BpKPgeoCxGaY16NZ20+KNZRhm3ny0FMvkCMRXw@mail.gmail.com>
In-Reply-To: <CAEp07h-NZpJ9BpKPgeoCxGaY16NZ20+KNZRhm3ny0FMvkCMRXw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: christopher.jones@oracle.com (Christopher Jones)



On 01/28/2014 12:36 PM, Martin Keckeis wrote:
> Am 28.01.2014 21:24 schrieb "Nikita Popov" <nikita.ppv@gmail.com>:
>>
>> On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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.
>>>
>>
>> Just to clarify my vote: I voted "No" on the RFC, but only because I think
>> the major extension source API break is better suited to PHP 6 than PHP
>> 5.6. I fully support merging this into master, as the first change for PHP
>> 6.
>>
>> Nikita
>
> Sadly...
> (From a long waiting Php user, who dont want to wait 2-3 years...)
>

The extension compatibility issue is not insignificant.  Each voter
will have a different idea of how best to take PHP forward while
keeping the current user base happy.

Personnaly, I'd be glad to see the size_t_and_int64 vote halted until
PHP 6 is discussed a little more.  This would give a clearer idea of
what BC breakages are likely in each release, and what the various
release timeframes are.

If the PHP 6 discussion doesn't happen or conclude quickly, then the
size_t_and_int64 vote can be restarted in time for any merge to 5.6.

Work on size_t_and_int64 and SAPI obsoletion etc should continue ready
for which ever branch it will be merged to.

I think I'm the only one (outside Anatol et al) actively looking at an
extension the new branch and have committed to it.  I've some more
OCI8 patches pending, and more investigation to do.  And then the
extension needs to be made compatible with older PHP releases.  In
summary: migration is not a search and replace operation.

Chris

-- 
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