Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86225
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXYaucdMdtDyzRADWE05OQkY=0OnFC11Y1QyPb7NQyoFYA@mail.gmail.com>
References: <CAGa2bXaFnkU7hqR56kGkWqbrc8KivGEjUCXLi=5cJ5wr7MCq4Q@mail.gmail.com>
	<CAMPTd_Ct6vScEChavHgeRScquCFYby80GzbPtze4sGofmzFwgw@mail.gmail.com>
	<CAGa2bXbECPLnScF3wZeUDJPr=YP8V2vOQMEdXVP53HT=xxvcTw@mail.gmail.com>
	<CAMPTd_BtYYUbUrMTSSX2z=x0h4s5r5Ad49T84QS47SZjqYHg-A@mail.gmail.com>
	<CAGa2bXYaucdMdtDyzRADWE05OQkY=0OnFC11Y1QyPb7NQyoFYA@mail.gmail.com>
Date: Thu, 14 May 2015 14:48:17 -0700
Message-ID: <CAMPTd_CSzofrUC9HXZ_3gvhux553v0oN2dVX4SdtNi7=COMHjg@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d04428cdc727eae051611afec
Subject: Re: [PHP-DEV] is_digits() and digits type
From: walterp@gmail.com (Walter Parker)

--f46d04428cdc727eae051611afec
Content-Type: text/plain; charset=UTF-8

For recordID parameters, I think the only to get what you want is use a
class and strongly type the objects. I deal daily with code that assumes
things that look like integers are integers. As far as integers go, 123456
and 000123456 are the same. As record keys, they don't have to be the same
(it is a bad design). Without adding a 64 int type to 32 bit PHP, you can
not fix this in 32 bit land and keep PHP looking like PHP.

I guess this breaks down to the following two choices: In 32 bit PHP, what
is the proper response to an API that uses 64 integers? Should the values
be treated as strings or as integers. If treated as strings, they they can
perform all the functions of database keys and any other purpose that
treats them as tokens. If used as integers, then you set your code up for
failure. Anybody that casts or coverts them to ints has just set themselves
up for failure at some point in the future.

I'm not sure how we can fix the problem of people that see something that
looks like an int so they want to call it an int, regardless of the fact
that that is the wrong thing to do. But I don't blame you, as this sort of
mislabeling happens throughout society (just look at politics and the
misuse of labels there).

As far as the idea that most PHP won't use type hints correctly (to me,
that reads "Most PHP programmers don't care about the code they write or
are too stupid to see the problems"), maybe we could require that PHP
programmers get a license that requires that they understand how to use the
language correctly. Maybe we could fire them or ask them to use a simpler
language that doesn't require them to understand important details. I hear
you can still get BASIC.

 If you don't want you code to break when you 64 bit ints, either check for
size type and blowup/give a warning that your library is not compatible
with 32 bit ints or face the reality that the keys must be stings or
objects if you want your code to run without errors on 32 & 64 systems
without error.



On Thu, May 14, 2015 at 1:17 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Walter,
>
> On Fri, May 15, 2015 at 2:49 AM, Walter Parker <walterp@gmail.com> wrote:
>
>> Adding a numeric pseudo type will not fix abuse, it will only change the
>> abuse. I don't think it is worth the effort. I also think it might a
>> slippery slope to lots of other pseudo types and other half ideas that will
>> add complexity to the language without much in the way of benefit.
>>
>
> Pseudo type is not abuse if it's there.
> Almost all PHP programs treated external values as string. PHP handled it
> somewhat nicely by type juggling.
>
> In PHP, integer like values are treated
>
> signed 32 bit int:  32 bit CPU
> signed 53 bit int:  32/64 bit CPU (IEEE 754 double)
> signed 64 bit int:  64 bit CPU
> arbitrarily int: 32/64 bit CPU (string digits is good enough for
> databases/etc IDs)
>
> If arithmetic is needed, we could assume it has at least signed 53 bit
> int. If arithmetic is not needed, we could assume
> arbitrarily int. I usually don't need integer arithmetic correctness much
> because most arithmetic are very
> simple. Examples are adding/subtracting date, stock, counter which will
> never exceeds signed 53 bit int range.
>
> On contrast, I need strict correctness for record IDs. Valid IDs should
> never raise error/exception.
>
> Use of type "int" type hint reduces reliable range to signed 32 bit int.
>
> The mixing of types, casts and validations can cause problems. I don't see
>> how adding pseudo types will actually fix this as this appears to a
>> validation problem and not a typing problem.
>>
>
> Validations should not cause problems. If it does, the way validating data
> is wrong.
>
> I understand what's wrong with "int" type hints, yet I have to fight
> against temptation
> using it when signed 64 bit int is enough for my code/system. Vast
> majority of
> PHP programmers would use "int" type hint without considering the
> limitation and
> consequence.
>
> Anyway, we need at least numeric value validation (safe cast) function.
> Without it,
> strict_types=1 is harmful especially because people will just use casts
> which hides
> problem is their code.
>
> I don't expect PHP's "int" type hint accept arbitrarily numbers even when
> GMP int
> is fully integrated. PHP is made for web and interaction. JSON supports
> "numeric"
> that has undefined(unlimited) precisions, databases support huge numbers.
> Advocating
> users to use "string" type hint for these seems impossible. We'll see the
> result soon.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>



-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--f46d04428cdc727eae051611afec--