Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.170 as permitted sender)
Message-ID: <55419C0C.7020207@gmail.com>
Date: Wed, 29 Apr 2015 20:05:48 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: Ryan Pallas <derokorian@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
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>
In-Reply-To: <CAGa2bXYk=2TVFv9aeDjVRpgLKFjhYx6YBCpmWo10u-Qv8b0zpg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Adding "numeric" type hint
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> How many of us are expected that
> 
> mydb_find_by_id(INT_MAX+1);
> Note: INT_MAX+1 is pseudo integer string value.
> 
> fails with fatal error? I guess it's not many.

I'm not sure what is the meaning of "INT_MAX+1 is pseudo integer string
value" - if it fits the integer, it's the integer, if it's a string that
looks like decimal rendering of a natural number that is equal to
INT_MAX+1, then it's not an integer, it's just a string. It can not be
used as integer.

If somebody voted on this RFC without expecting it, that means they did
not understand the RFC. I don't know what can be done about people
voting for RFCs they don't understand - we can't take an exam before
voting. We expect people first understand it then vote, and assume
everybody who votes understands what it means and accepts the
consequences.

> Users are recognized record ID as integer even if it's a string integer
> indeed.

There's no such thing as "string integer". It's either string - which
can be convertible or not convertible to integer - and there's actual
integer value.

> I think many, if not most, users are not aware that db record ID field is 
> "string integer" . As long as users do not apply arithmetic, string integer 
> worked perfectly with PHP. I'm saying this is a tradition.

I don't see where you derive such "tradition" from. PHP never worked
this way. The only difference is that before you'd get something like
INT_MAX or -INT_MAX or 0 or whatever random value after conversion. I
don't see how that would be better than fatal error, really.

> Most obvious use case is record ID that I mentioned above, but it's not
> limited to record ID. e.g. all database numeric values/JSON numeric/
> PHP array integer type key beyond INT_MAX/MIN.

You can't have integer array key beyond integer, that is a logical
impossibility. As for external values, external value can be anything -
row of ones, random binary noise, string "porcupine", anything. You
can't expect it to be convertible to integer. You'll have to check
anyway. "numeric" type is not going to help you.

> Great. I think "int"/"float" type hint is too strict even under weak mode. 
> Therefore, I want to have "numeric" type hint at least.

I don't see how this helps anything. "numeric" is not a type, it is a
validation of a string form. As such, it has very little to do with PHP
types.

> Having "numeric" or accepting huge value(including GMP) for "int"/"float" 
> should be acceptable. IMHO.

That negates the whole purpose of having "int" type, since what comes
out of it is not int anymore.

> As I wrote, huge numbers are valid data for databases. I don't want to have

String "porcupine" is a valid data for database too. Should we have a
type that says "number or string 'porcupine'"? Both are valid data for
DB. But they do not form a type.

> DoS incident just because PHP limits numbers to native type range
> while databases accept these larger values as valid values.

Databases accept *anything* as valid values. If you expect this to fit
PHP's scalar types, you need to check. Otherwise, you need to use PHP
type that can accommodate anything, namely - string.

> We may have integrated GMP float in near future also. Accepting compatible
> value/type is mandatory if it's a type "hint" for weak mode. I don't
> think we 
> decided to have type declaration(type enforcement), do we?

We can accept compatible values. The question is what to do with
*incompatible* values. Accepting those is not really possible within
typed parameters semantics.

-- 
Stas Malyshev
smalyshev@gmail.com