Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86180
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5552540C.9000205@lsces.co.uk>
References: <CAGa2bXaFnkU7hqR56kGkWqbrc8KivGEjUCXLi=5cJ5wr7MCq4Q@mail.gmail.com>
	<C4521D8F-A682-407A-BC74-646468DCA225@gmail.com>
	<5552540C.9000205@lsces.co.uk>
Date: Tue, 12 May 2015 13:05:12 -0700
Message-ID: <CAMPTd_C4bj85opcmneC5+pbUoDVzkTPS289Qj0sJZ+1rneYf5g@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c7e26199ee40515e803ae
Subject: Re: [PHP-DEV] is_digits() and digits type
From: walterp@gmail.com (Walter Parker)

--f46d043c7e26199ee40515e803ae
Content-Type: text/plain; charset=UTF-8

On Tue, May 12, 2015 at 12:27 PM, Lester Caine <lester@lsces.co.uk> wrote:

> On 12/05/15 19:55, Rowan Collins wrote:
> > For instance, valid input for a 64-bit signed integer in a database
> could include:
> > - any PHP native integer (assuming nobody builds with 128-bit ints!)
> > - any string consisting of all digits, such that when interpreted as an
> integer the value won't exceed 2^64-1
> > - any string consisting of a '-' followed by digits, such that the
> magnitude of the integer interpretation wouldn't exceed 2^64
> > - any PHP float with no fractional part, maybe capped to a magnitude
> less than 2^53 for safety
>
> BUT
> In INTEGER in a database is 32 bit and will remain 32 bit, just as
> SMALLINT is 16 bit ... 64 bit is BIGINT and so the whole concept of
> simply ignoring 32 bit and handling them instead as 64bit is wrong!
> So type hints are broken before they start!
>
> --
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Yes, you understand the problem. PHP type hints are for PHP variables and
PHP types. External applications that have types with the same names and
different sizes can not use PHP type hints. Until and unless a majority
block of voters appears and is willing to add a full suite of types that
match external applications (8, 16, 32, 64, etc bit Integers, 32, 64, 80
bit floats, plus maybe the decimal types and the bignum types), you will
not be able to create scalar variables that track the types of external
data types. As some of the major committers are actually against adding
this sort of complexity to PHP, it is unlikely to happen.

For external data types, I don't see a good path other than classes for
tracking the data types.

How about a different type of RFC. How about adding the ability to add your
own scalar types to the language. Then people that want to write C++/Java
in PHP can define all the types they like. I'm sure that It could be done
in time for a PHP 8 or PHP 9.



Walter


-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--f46d043c7e26199ee40515e803ae--