Hi Stas,
On Thu, Apr 30, 2015 at 12:05 PM, Stanislav Malyshev <smalys...@gmail.com>
wrote:
> > 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.
>
I hope everyone voted "yes" and users realize the consequence.
I don't have problem with this if I could write _ALL_ of PHP code that I
use.
Obviously, I cannot have that much amount of time.
> 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.
>
No there is not.
I have read so many buggy casts for record IDs in past.
i.e. "SELECT * FROM table WHERE id = ". (int)$id
"Integer like string" must stay as "string" to avoid bugs.
I wonder about how many of users write function with correct type hint.
Wrong: mydb_find_by_id(int $id) { // find it }
Correct : mydb_find_by_id(string $id) { // find it }
"int" Cast is bad. Incorrect "int" type hint worse as it could trigger DoS.
> 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.
>
Whether like it or not, database values are treated as string. Some of
values are treated as int, but integer columns like record IDs are treated
as "integer like string". PHP Users didn't care much about types used,
and they used "integer like string" as it is.
As a result, database record ID/etc are treated correctly.
I saw many buggy int casts for record IDs. Therefore, I'm expecting buggy
type hints as well.
There should be relaxed type hint for numeric types.
- Have numeric
or
- Relax weak mode int/float type hint like CoerciveSTH
> 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.
>
numeric type is useful for numbers that could be out of PHP int/float range.
> 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.
>
If anyone really need some parameter to be int/float, they can use "strict"
mode.
Isn't it enough?
>
> > 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.
>
It's not all, but the main issue here is 32 bit CPU & PHP int is too small
for
database record IDs.
> 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.
To maximize compatibility, arbitrarily size of int/float like string/value
should be
accepted as numeric(or int/float).
We have issues for type handling. One is type hint spec/behavior, another
is
cast without any errors. We need "cast with errors" feature so that users
can
handle range error easily.
I'm grateful if int/float restriction is relaxed. Otherwise, having
"numeric" type hint
is mandatory to avoid type massive hint misuse. Writing big warning "Do not
use
'int' type hint for database record IDs/etc, but use 'string' type hint and
validate by
yourself" wouldn't help much.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
