Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker.
Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation.
I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well.
So, anyway, here’s the RFC, including the voting widget:
https://wiki.php.net/rfc/bigint
Voting starts today (2015-02-15) and ends in 10 days (2015-02-25).
If you have any queries, please ask.
Thanks!
--
Andrea Faulds
http://ajf.me/
The time range is Chinese lunar new year. I am not sure @laruence and
@reeze be on holidays or not.
The vote time range can be extended ?
I have no the ability to vote. but i guess this RFC is very well for
PHP programmers.
Appreciate your time.
Netroby
Hi Netroby,
The time range is Chinese lunar new year.
Oh! My bad, I was unaware of that. (I really should’ve noticed that, given I am learning Mandarin.)
When do festivities etc. end? What would be a good time to extend it to?
Thanks!
--
Andrea Faulds
http://ajf.me/
I do not know their plan. but in china, we will happy in our holiday
till 2015.03.05 (The last important holiday The Lantern Festival )
then we will back to work.
This is traditional chinese holidays.
Learn mandarin should be fun, welcome you guys come to china . It's
now our very important holidays, every where we should be happy than
normal days.
But if you hurry and care about the votes. you would not be waiting
for so long time. that's not very important.
Appreciate your time.
Netroby
2015-02-15 12:04 GMT+08:00 Andrea Faulds ajf@ajf.me:
Hi Netroby,
The time range is Chinese lunar new year.
Oh! My bad, I was unaware of that. (I really should’ve noticed that, given I am learning Mandarin.)
When do festivities etc. end? What would be a good time to extend it to?
Thanks!
--
Andrea Faulds
http://ajf.me/
Hey:
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker.
for such a big change, the implementation self is also important,
there was some RFC accepted with "not good" implementation, which
cause lots of troubles for us to maintaining .Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation.
I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well.
from your RFC:
"
but obviously the implementations of anything dealing with integers
may need to be changed."
this sounds too much compare to the benefits it brings.. (User can use
bcmath or other similar thing to deal with big int).
and actually, I'd prefer this to be a extension instead of get it into core..
too much changes for little gains..
Thus, I voted -1 on this.
thanks
So, anyway, here’s the RFC, including the voting widget:
https://wiki.php.net/rfc/bigint
Voting starts today (2015-02-15) and ends in 10 days (2015-02-25).
If you have any queries, please ask.
Thanks!
--
Andrea Faulds
http://ajf.me/--
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Hi,
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker.
for such a big change, the implementation self is also important,
there was some RFC accepted with "not good" implementation, which
cause lots of troubles for us to maintaining .
This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen.
Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation.
I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well.
from your RFC:
"
but obviously the implementations of anything dealing with integers
may need to be changed."this sounds too much compare to the benefits it brings.. (User can use
bcmath or other similar thing to deal with big int).
It’s not a massive change. All the places in core have already been changed. Most extensions taking integers do so via zpp’s “l” type (or FAST_ZPP’s Z_PARAM_LONG), which handles bigints properly. The main issue is functions accepting zvals (“z” or Z_PARAM_ZVAL). In such cases, the change is usually two lines of code to add an IS_BIGINT case to a switch.
and actually, I'd prefer this to be a extension instead of get it into core..
too much changes for little gains..
Thus, I voted -1 on this.
Alright, I can understand your perspective.
Andrea Faulds
http://ajf.me/
Hi,
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker.
for such a big change, the implementation self is also important,
there was some RFC accepted with "not good" implementation, which
cause lots of troubles for us to maintaining .This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen.
At 4 weeks before the feature freeze, we pretty much have to vote for
the implementation as well. Every feature that requires significant work
puts more pressure on a small group of developers and takes their time
away from working on stabilizing the existing code base.
My no vote is based on looking at the implementation, the size of the
patch and the destabilizing changes to the extension API weighed against
its benefits.
-Rasmus
Hi,
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker.
for such a big change, the implementation self is also important,
there was some RFC accepted with "not good" implementation, which
cause lots of troubles for us to maintaining .This vote isn’t to be thought of as accepting the implementation, merely the feature. If the implementation isn’t good enough, the feature could actually be dropped for PHP 7, as much as I hope that won’t happen.
At 4 weeks before the feature freeze, we pretty much have to vote for
the implementation as well. Every feature that requires significant work
puts more pressure on a small group of developers and takes their time
away from working on stabilizing the existing code base.
No we do not. Many things are not yet stable or will change until 1st
beta (or after). It is not realistic nor fair to ask for perfect
implementation for such thing. And the time argument is really just an
excuse, we got the same issue with the 64bit patch, asking for a
perfect patch while php7 did not event exist at this point.
It only tells me we need a two phases RFCs for proposals like that. Or
proposers simply waste their time because of such votes.
My no vote is based on looking at the implementation, the size of the
patch and the destabilizing changes to the extension API weighed against
its benefits.
Too bad.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi everyone,
I should’ve done this a long time ago, but I’m going to hold a vote on this RFC. The implementation isn’t finished, but the remaining work isn’t impossible to surmount (though help would certainly be appreciated). RFCs can be put to vote without implementations (or so says https://wiki.php.net/rfc/howto), so the fact the implementation is unfinished isn’t necessarily a blocker.
Putting it to a vote, finally, means I can stimulate further discussion (let’s face it, most discussion on a given RFC happens during voting), and importantly, see how much support the RFC has in order motivate myself to finish the implementation.
I think this would be a useful feature for PHP. It brings PHP into line with other modern dynamic languages in having integers of arbitrary size. It makes integer behaviour both more intuitive and more consistent across platforms. It (finally) adds a means for handling of 64-bit (and larger) integers in 32-bit environments. I think allowing integers to grow as needed and not having to worry about platform-specific details is very “PHP”, as well.
So, anyway, here’s the RFC, including the voting widget:
https://wiki.php.net/rfc/bigint
Voting starts today (2015-02-15) and ends in 10 days (2015-02-25).
If you have any queries, please ask.
Thanks!
I think this adds a ton of unnecessary complexity and isn't worth the
breaks or performance degradations that come with it.
We already have big integer support in the form of the GMP extension,
and it is very clear when you are working with arbitrary length
integers. But instead this patch adds GMP as a dependency and hides it
away internally (or for a bigger performance hit, LibTomMath).
Extensions "that deal with numbers" are all going to need updating. So
probably every extension?
You talk about eventually deprecating ext/gmp and moving it to PECL.
Definitely not acceptable.
Sorry, the fixed size integer data type is far too baked-in and
useful. I don't see any gain from this patch except hidden performance
penalties, breaks, and extra work for everyone in maintaining it and
other extensions. I'd rather big int usage was kept verbose and
conscious.
-1
Hi,
I think this adds a ton of unnecessary complexity and isn't worth the
breaks or performance degradations that come with it.We already have big integer support in the form of the GMP extension,
and it is very clear when you are working with arbitrary length
integers. But instead this patch adds GMP as a dependency and hides it
away internally (or for a bigger performance hit, LibTomMath).Extensions "that deal with numbers" are all going to need updating. So
probably every extension?
Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did.
You talk about eventually deprecating ext/gmp and moving it to PECL.
Definitely not acceptable.
I talk about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it.
I said “might” because it’s not part of the proposal, it is merely a thought.
Sorry, the fixed size integer data type is far too baked-in and
useful.
I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range?
I don't see any gain from this patch except hidden performance
penalties, breaks, and extra work for everyone in maintaining it and
other extensions. I'd rather big int usage was kept verbose and
conscious.
I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic.
--
Andrea Faulds
http://ajf.me/
Extensions "that deal with numbers" are all going to need updating. So
probably every extension?Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did.
The real-world performance gains of ng are significant. Everything is
a trade-off. Having to change exts because the guys behind ng have
made (potentially) "80% of all websites" faster is acceptable - in my
opinion.
You talk about eventually deprecating ext/gmp and moving it to PECL.
Definitely not acceptable.I talk about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it.
I said “might” because it’s not part of the proposal, it is merely a thought.
The GMP ext offers a lot more than arbitrary precision arithmetic.
There's a slew of functions there that go hand in hand with big ints
and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name
a few. There are applications, both proprietary and open that depend
on these. I'd personally be willing to help bring more functionality
to ext/gmp rather than lose all of these important functions to PECL.
Sorry, the fixed size integer data type is far too baked-in and
useful.I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range?
Among other thing the behaviour of overflow and shift operations are
well documented and understood quirks of fixed size integer types.
I don't see any gain from this patch except hidden performance
penalties, breaks, and extra work for everyone in maintaining it and
other extensions. I'd rather big int usage was kept verbose and
conscious.I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic.
A weird extension? The base library of which you are using to back
your big int implementation.
DoS against libgmp is really stretching it here. Yes you can cause all
kinds of horrible crashes if you try and do something ridiculous, but
that's why you have a programming language that gives you everything
you need to sanitise inputs to prevent it.
Extensions "that deal with numbers" are all going to need updating. So
probably every extension?Anything accepting a zval rather than a long through zpp, but the changes are quite small in most cases. It’s a much smaller change than, say, what phpng did.
The real-world performance gains of ng are significant. Everything is
a trade-off. Having to change exts because the guys behind ng have
made (potentially) "80% of all websites" faster is acceptable - in my
opinion.
Let be serious here, the zpp changes be for 7 (pls stop calling that
ng, it is 7 now :) or for this RFC is irrelevant. An ext wants to
support bigint? fine. It can't? Then it will fail or cast with warning
or notice.
You talk about eventually deprecating ext/gmp and moving it to PECL.
Definitely not acceptable.I talk about it. I’m not saying we’ll do it. It’s a future possibility: since it would be made largely redundant by large integer support in core, we might eventually get rid of it.
I said “might” because it’s not part of the proposal, it is merely a thought.
The GMP ext offers a lot more than arbitrary precision arithmetic.
There's a slew of functions there that go hand in hand with big ints
and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name
a few. There are applications, both proprietary and open that depend
on these. I'd personally be willing to help bring more functionality
to ext/gmp rather than lose all of these important functions to PECL.
Fully agree, gmp allows more. And it should not be removed. While
"native" bigint support is really handy and I can see many benefits.
Using GMP for other features remain important.
Sorry, the fixed size integer data type is far too baked-in and
useful.I could understand your perspective if PHP had modular arithmetic like C and such, but it doesn’t. So I don’t understand why it is “far too useful” - what usefulness is being lost by extending its range?
Among other thing the behaviour of overflow and shift operations are
well documented and understood quirks of fixed size integer types.
Does that mean it should not be improved? Aka more obvious and less quirky?
I don't see any gain from this patch except hidden performance
penalties, breaks, and extra work for everyone in maintaining it and
other extensions. I'd rather big int usage was kept verbose and
conscious.I see a clear gain: we clean up almost every integer overflow edge case, integer overflow handling is more intuitive, we support large integers safely on 32-bit, and we don’t require you to use a weird extension that may crash the PHP interpreter and DoS your web host in order to do large number arithmetic.
A weird extension? The base library of which you are using to back
your big int implementation.
I agree here too. gmp is just fine. I see this RFC as a different
thing. Having bigint support in the engine makes sense regardless of
gmp. Other languages have it and are very happy with that. It is
simply way easier and cleaner to use than relying on an ext (while
Nikita's patch for operators overloading for exts makes things
better).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org