Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender)
Message-ID: <543CE41B.5020308@sugarcrm.com>
Date: Tue, 14 Oct 2014 01:51:39 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me>
In-Reply-To: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!


> Since I don’t want this to languish as a ‘Draft’ forever, despite the
> patch being incomplete, I am finally putting the Big Integer Support
> RFC “Under Discussion”.
> 
> The RFC can be found here: https://wiki.php.net/rfc/bigint

This introduces new type, IS_BIGINT. However, given that GMP now
supports arithmetical operations, I wonder if it won't be easier to do
it in slightly different way, specifically create a hook that is going
to be called when an operation is about to cause over/underflow and let
GMP hook there and produce a GMP number (I'm not sure about the exact
details how to actually do it, so it's just an idea now, but if it makes
sense we can try to work out technical details).

Of course, this would require some rough edges to be polished, such as
what happens if you try to use it as int, or convert, etc. but this is
already present with IS_BIGINT too, and additionally we already have
conversion handlers for objects, which aren't consistently used in all
cases but can be made so. The benefit is we're not creating anything
completely new, we just improving how objects work.

This would also allow anybody who doesn't like GMP big integers easily
implement their own module to replace them.

Moreover, this also allows to make the support for bigints optional -
i.e., if you don't need bigints, you don't have to carry GMP and thus do
not have to be bound by its license.

What do you think?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/