Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78039
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender)
Message-ID: <543D5C78.9040905@sugarcrm.com>
Date: Tue, 14 Oct 2014 10:25:12 -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>
CC: PHP Internals <internals@lists.php.net>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com> <C545E75D-109A-4348-9B7E-CDE3A6FD6F57@ajf.me>
In-Reply-To: <C545E75D-109A-4348-9B7E-CDE3A6FD6F57@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: smalyshev@sugarcrm.com (Stas Malyshev)

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

> 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.

> 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. 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.

> Making it optional destroys most of the benefits of the RFC. Instead
> of reducing platform differences, it adds a massive new one. Now

I'm not saying we have to make it optional. I'm just saying it's possible.

> 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. If it's there, you just continue working.
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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/