Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <543A3326.3020309@lsces.co.uk>
Date: Sun, 12 Oct 2014 08:52:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <54385BC4.8030405@lsces.co.uk> <D9BBD948-969E-42AC-A83A-927E6BE09E6E@ajf.me> <54386E55.20407@lsces.co.uk> <5A30388D-AD64-4C6A-8547-A0C98D834A8A@ajf.me> <5438F4D1.1080206@lsces.co.uk> <5439D642.10804@gmail.com>
In-Reply-To: <5439D642.10804@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: lester@lsces.co.uk (Lester Caine)

On 12/10/14 02:15, Rowan Collins wrote:
> On 11/10/2014 10:13, Lester Caine wrote:
>> BIGINT is the SQL99-compliant 64-bit signed integer type
> 
> It's a matter of context. In C, and therefore in related discussions
> (which includes the internals of PHP), integers are referred to as
> "short" (for 16-bit), "long" (for 32-bit) and "long  long" (for 64-bit),
> but never as "big". SQL is unusual in calling a 32-bit integer "BigInt"
> rather than some variant of "long" or "32", and since we're not
> discussing databases here, it's of only marginal relevance.
> 
> I can see why, having spent more time in SQL than C, you might jump to
> the wrong meaning of "BigInt", and it might even be worth considering
> this potential confusion when writing the end-user documentation for
> this new feature, should it be implemented.
> 
> But, as others have said, that's really not an issue which should
> dominate the discussion at this stage.

There were only two things on my wish list for PHP6 ... Unicode and
proper handling of BIGINT. The use of a 64 bit value in databases as the
primary key has been long established and a related 64 bit element is
timestamp, While the timestamp can be handled as two 32 bit values (on
some databases!), the primary key is a 64 bit number. Many database
engines started using 64 bit builds years ago and have native 64bit
integers, but still handle that on 32bit builds as well. Bringing that
key into PHP has always been something of a gamble as to how it will be
represented, but the database drivers do seem to line up now.

You are right that *I* had miss interpreted Andrea's use of bigint but I
have always commented on it in the context of using a 64bit integer key
for arrays. In relation to the CURRENT discussion, if a 32bit build is
going to default to a 'BigInteger' string rather than a simple 64bit
value then there is a problem. I would rather THAT did not happen, but
it still leaves the problem of 64bit keys for arrays in 32bit builds.
There are many reasons why a 32bit primary key was limiting in databases
and while I have no doubt at some point it will be upgraded to 128bit, a
64bit value for timestamps and record counts will last long after most
of even you youngsters have past away? BigInteger is a PHP8 problem
64bit array keys is the PHP7 one!

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk