Re: [DRAFT][RFC] Big Integer Support

On 26 Jun 2014, at 18:33, Rowan Collins <rowan.collins@gmail.com> wrote: > Chris Wright wrote (on 26/06/2014): >>> I'm assuming if bigint keys were available, PHP_INT_MAX would still have the >>> same value, but PHP_INT_MAX + 1 would become a valid key, making this work >>> transparently. >> PHP_INT_MAX would probably need to be renamed (i.e. deprecated and >> replaced) because it would become a misnomer - the max*PHP* int is no >> longer known because it is limited only by memory. > > An interesting thought. Is there really much value in renaming it though? It would cause a > compatibility break (once the deprecation period expired) for something which could easily be > covered by documentation. If done right, the BigInt support would simply make the constant > unnecessary in the majority of cases. Right. Myself, I’m in favour of keeping PHP_INT_MAX around. The name might be misleading, but it’s still important in a few places. So long as the documentation makes this clear, it’s not a problem. Actually, I’d like to add a new constant perhaps, PHP_INT_MIN. It seems silly that we have a _MAX yet no _MIN despite having signed integers, especially since your minimum can’t be typed as a literal (longstanding bug, one that bigints happen to “fix” as it would be a bigint, but it should really be a long), and it’s -(PHP_INT_MAX - 1) not -PHP_INT_MAX. > It's also not entirely clear to me what it could be renamed *to* which was any more > appropriate. PHP_LONG_MIN perhaps, but so far as user land cares, long and int are synonyms. I don’t want to rename it, anyway. -- Andrea Faulds http://ajf.me/