> On 21 Oct 2014, at 09:35, Dmitry Stogov <dmi...@zend.com> wrote: > > Hi Andrea, > > Why don't you use the ability of operator overloading? (it's in the engine > since 5.6).
I've already answered this in this thread, but I'll answer it again if I must. > > BIGINT don't have to be completely transparent. If user would like to work > with BIGINT, let them crate PHP objects explicitly and then use operator > overloading. e.g. Well, they already can. ext/gmp exists. > Your solution would allows writing the same without BIGINT, but not for free. > I expect, it'll make some slowdown for all PHP scripts, independently, if > they use BIGINT or not. > I'll try to take a deeper look into the patch later... > > Could you provide some benchmark results, comparing your patch with master? So, the point of this RFC is basically to make PHP a language where, like Python, Haskell, Prolog or (de jure but not de facto) Dart, integers can be arbitrarily large and you never have to worry about overflow. Instead of applications which definitely need bigints using them explicitly, all applications can now support integers of any size transparently, essentially for free. It also makes the language more intuitive in a way. Plus, it's one less cross-platform difference so code is more portable. You're right it might not actually be free, though. I'll need to run some benchmarks - will do later today if I remember. It shouldn't be any slower than master, though. All it does is change what we do in our usual overflow checks, which we already had. Now, once you've overflowed and got a bigint, obviously they're slower than floats. However if you need floating-point performance you can explicitly cast to double and deliberately lose accuracy. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
