> On 21 Oct 2014, at 09:35, Dmitry Stogov <[email protected]> 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/