On 14 Oct 2014, at 18:25, Stas Malyshev <smalys...@sugarcrm.com> wrote:
> Hi! > >> I'm not sure what this would solve. Sure, you could just use objects >> instead of a new type, but both present exactly the same challenges. >> Adding a new type isn't hard in itself. The problem is updating >> everything which handles numbers and their associated tests. This > > Exactly. Since objects are convertable to numbers (and to anything, in > fact) we get double profit here - we make objects work better and we > achieve big integer support. And we don't need to handle new type where > we don't need numbers Handling a new type in cases where we don’t need numbers isn’t really a problem. > >> doesn't make my job any easier. It also wouldn't cover a few places >> that a new type can, like constants. Another problem is this means > > I'm not sure I see much case for bigint constants. Would be pretty hard > for me to come up with a case where you need such a constant, and if you > do, you could just have a string constant and convert it to GMP in runtime. Still, it’s inconvenient. More for developers to worry about. > >> that bigints are a separate thing from ints, meaning users have to >> worry about a new type which sometimes behaves differently. This >> isn't good. Under this RFC's proposal, however, bigints are a mere >> implementation detail. So far as the user cares, there are just >> ints. > > No, they are not implementation detail - they are whole new type, which > means every extension and every piece of PHP code aware of types now > needs to know about it and needs special code to handle it. No, only extensions. It is *completely* transparent to userland. That’s the whole point. > I.e. you > pass it to mysql - mysql needs to handle this type. You pass it to SOAP > - SOAP needs to handle this type. Etc. But if it's an object, they > already deal with objects, one way or another. 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. > >> developers have to check whether or not bigints are enabled and have >> two different code paths. That's much worse than the status quo. > > I don't see why you'd have two code paths. If you need bigints and they > are not there, then you just fail, like with any extension your code > needs and is not installed. 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. > All the code existing now doesn't need bigints, and even in the future > most code won't need it. But for some code it would just work like > before, only with unlimited range now. 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. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
