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