Hi! > Still, it’s inconvenient. More for developers to worry about.
I still have no idea why one would need a bigint constant, could you give an common example where you would do that? > No, only extensions. It is *completely* transparent to userland. > That’s the whole point. I'm not sure how it can be completely transparent if it's a different type. Is it still identifying as int? In this case, this is dangerous as some functions may not be able to accept big integers when accepting int arguments, but checks for is_int, etc. would pass. > Yes, but they don’t handle large integer objects already. So you pass > it a GMP object, it converts to a string, then that overflows and you > end up with a float when it converts it to a number. Which isn’t what > you wanted. Or, it handles it as a string, which is also not ideal, > as while a string and an int may be the same thing to some > extensions, they are not to others. If it's not, the extension has to handle it, the same way it has to handle bigint anyway if it makes difference for it. The point is many common cases are already covered, e.g. if the extension just needs a string, or if the bigint actually represents a small int, etc. > It’s not about “extensions your code needs”. If you need ext/gmp, you > can already require it. This RFC is about removing cross-platform > integer handling differences. But nothing changes there - it is still removing the diffs and it still requires GMP. The only change is you're not paying for it if you don't need it. > No, but existing code does have to handle float overflow. If you > allow that to optionally be int overflow, you now need to worry about > handling both. What's "float overflow"? I'm not sure I'm getting your point here. You don't need to handle anything - if your code doesn't care about big ints, you just do math as usual. If it does, then you have to check big ints are there, then do math as usual but be aware that int can be now of two different types. I don't see any difference from the RFC here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
