Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZ5rd0-4bnKNtSyjxso=8K=MyZsULBLby-5+TgfVk6Y0A@mail.gmail.com>
References: <CAGa2bXYzp3XimLXxC+Py2t1DWhCfX8coTdYHzf6zEiKdxA7r8Q@mail.gmail.com>
	<55401F31.9030703@gmail.com>
	<CAObuZduZBM0GyWJMA1Fd7eCgPE4vFFZrrhpREQ50a4QJhG6Nvg@mail.gmail.com>
	<CAGa2bXar_oXrsPAErNx5BUdkFAy-p8-D0tfhc3pAnDTGBGJJ7Q@mail.gmail.com>
	<55416849.9010808@gmail.com>
	<CAGa2bXbkCx2Nqb9YBut3id4N=nhjLBGPN8Ucrx7R6mRnGjB2og@mail.gmail.com>
	<5541753D.5050908@gmail.com>
	<CAGa2bXYk=2TVFv9aeDjVRpgLKFjhYx6YBCpmWo10u-Qv8b0zpg@mail.gmail.com>
	<55419C0C.7020207@gmail.com>
	<CAGa2bXaPAwFs=2=wHAE615dhyFO_5sUnKV4X2cMVFJM9xoG1wg@mail.gmail.com>
	<5541C0E0.2080006@gmail.com>
	<CAMPTd_AK8sr2EVH38wWmv1LzRp1=ShA2uNon=+cPYukwDUG2LA@mail.gmail.com>
	<CAL0xaBGx_JYuduoAFAoNKNWOa8JXtUi5hJnaNR1_c3eFYg8NkQ@mail.gmail.com>
	<CAGa2bXZ5rd0-4bnKNtSyjxso=8K=MyZsULBLby-5+TgfVk6Y0A@mail.gmail.com>
Date: Thu, 30 Apr 2015 00:03:22 -0700
Message-ID: <CAMPTd_D5j7ma0C4SN5SCrMrnDaC8J_kE5TppSw_Xc+Nkkmt15A@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e016817e0f411760514ebb0f8
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: walterp@gmail.com (Walter Parker)

--089e016817e0f411760514ebb0f8
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 29, 2015 at 11:54 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Arvids,
>
> On Thu, Apr 30, 2015 at 3:40 PM, Arvids Godjuks <arvids.godjuks@gmail.com>
> wrote:
>
>> Stop trying to fix clever idiots from shooting themselves in the foot. The
>>> standard result from these actions is to make life a pain for regular or
>>> better programmers while only adding mild speed bumps to those clever
>>> idiots.
>>>
>>> Things like a numeric type will only encourage the clever idiots to write
>>> half broken code.
>>>
>>
>> Hello, just want to chip in.
>>
>> I use "INT UNSIGNED" for the MySQL primary keys since ages, because
>> negative primary keys make no sense. Well, mostly ID's for the records
>> actually can stay strings, but I will have to remember to use a string type
>> hint every time I pass a record ID. I expect a lot of times to forget that
>> and write int...
>> I was bitten a few times by the limits of 32 bit integer sizes too (moved
>> to a 64 bit server that time), but there are also unsigned 64 bit integers
>> that can and will be used in math operations and passed around. And we
>> don't have the "unsigned int".
>>
>
> Use of unsigned int8 for ID makes sense almost always if database supports
> it.
> I may do such mistake even if I know I should use "string" (or "numeric")
> for record IDs once I
> start using type hints.
>
> Okay, we have GMP. I will have to use it. But let me just ask - if I work
>> with a DB handling 64 bit integers (all I know handle them) or use a
>> DECIMAL field - automaticly use GMP then? Oh gosh....
>>
>
> I'm planning to introduce type affinity like SQLite. Then appropriate
> types for the value may
> be used automatically/semi-automatically. It's good for both security and
> performance.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>

Great! A Class or RFC that defined types that mapped one to one to DB types
sounds useful.

But this is not the same thing as generic pseudo type that are little more
that predefined regexs applied to strings (a.k.a the numeric type).



Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--089e016817e0f411760514ebb0f8--