On Tue, Jan 28, 2014 at 9:33 PM, Pierre Joye <
[email protected]> wrote:
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.
Sad. As the work for pecl extensions is really not as large as you
think, fairly straight forward. The vote for php6 is not running now.
There is no option for PHP 6 as what can be done in php 6 internally
is much larger and would allow more breakage. On the other side, we
provide options to minimize the work for the extensions developers in
order of magnitude smaller than the changes we introduced in the past
for the OO APIs for example. Anyway, sad that you voted no for
something as important than true 64bit support.
Maybe I'm indeed overestimating the impact. Could you please link to the
source-code for a PECL (or other third-party) extension that was ported to
be compatible with the new API, so people can see the actual impact this
makes? (Hopefully some ext that requires compat across multiple versions
like 5.3+ and has non-trivial amount of code and functions, like a few
dozen.) I couldn't find an example in RFC, but maybe I just missed it. Only
saw small snippets in there.
Nikita
You could do a diff with OCI8 on str_size_and_int64 vs. master to see
one example.
I also have some additional unmerged patches related to a comment you
may see "/* XXX we assume that zend-zval len has 4 bytes */" since the
zval len is now a size_t and no longer 32 bits. I have more investigation
to do.
If the ZPP specs are not portable (vote #3), an additional 53 calls to
it will need #ifdef'ing so the code base is portable to older PHP
releases (because OCI8 is also released on PECL).
Chris