Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86222
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbECPLnScF3wZeUDJPr=YP8V2vOQMEdXVP53HT=xxvcTw@mail.gmail.com>
References: <CAGa2bXaFnkU7hqR56kGkWqbrc8KivGEjUCXLi=5cJ5wr7MCq4Q@mail.gmail.com>
	<CAMPTd_Ct6vScEChavHgeRScquCFYby80GzbPtze4sGofmzFwgw@mail.gmail.com>
	<CAGa2bXbECPLnScF3wZeUDJPr=YP8V2vOQMEdXVP53HT=xxvcTw@mail.gmail.com>
Date: Thu, 14 May 2015 10:49:04 -0700
Message-ID: <CAMPTd_BtYYUbUrMTSSX2z=x0h4s5r5Ad49T84QS47SZjqYHg-A@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e016817e0f8e8b105160e579c
Subject: Re: [PHP-DEV] is_digits() and digits type
From: walterp@gmail.com (Walter Parker)

--089e016817e0f8e8b105160e579c
Content-Type: text/plain; charset=UTF-8

In C, the int data type is defined as being at least 16 bits in size. Long
is defined as being at least 32 bits and long long is defined as being at
least 64 bits in size. The standard further recommends that the size of int
be the most natural and efficient for the processor (i.e. 16 on 16 bit
processors, 32 on 32 bit processors, 64 on 64 bit processors). The C99
standard added standard types for integers that had defined sizes (the
8bit, 16 bit, 32 bit and 64 bit integer types). In Java, the sizes are
fixed, but I think you missed my point as there are multiple integer types
not that they change sizes.

PHP was written to use the first suggestion (integers being the natural
data size of 32 or 64 bit). To keep PHP simple, there is a desire to not
introduce several different integer sizes in PHP. Your right, this does
make it harder for people that want to use 64 bit integers on 32 bit
systems as 64 bit integers. For those people, they will have to use strings
or bignum. Given the lack of desire for this addition, the relatively small
number of PHP developers, and the idea that this is a legacy issue, I'd be
surprised if you. could get support for this.

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.

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.


On Thu, May 14, 2015 at 12:16 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Walter,
>
> On Tue, May 12, 2015 at 11:25 AM, Walter Parker <walterp@gmail.com> wrote:
>
>> You know, given how worried you seem to be about this issue, could you
>> booby trap your so that if the developers use the wrong type (int vs.
>> string) the program throws fatal errors with nasty error messages that
>> explain how much trouble the developer is in at the userland code level?
>>
>> While I like the of protecting idiot developers from themselves, I'm
>> still not sure that this isn't a half solutions that just hide the pieces
>> of the problem that it doesn't solve.
>>
>> I don't think we can solve the problem of developers not writing code
>> correctly or QA would mostly be out of job (instead of being a growth
>> segment).
>>
>> How about a full type system that would make Java programmer scream? I'm
>> sure with a bit of thought we can make one heavier than Java.
>>
>
> Java is not PHP.
> Java does not have 32 bit int on 32 bit machines, 64 bit int on 64 bit
> machine.
> Java has concrete byte, short, int, long type. It's whole different story.
>
>
>
> BTW, I noticed that mt_rand() behavior has changed to raise E_WARNING for
> too large numbers.
> This is good change because PHP is known to generate very weak random
> number with invalid
> min/max.
>
> [yohgaki@dev ~]$ php-5.6 -r "var_dump(mt_rand(222,
> '99999999999999999999999'));"
> int(115282844144104926)
> [yohgaki@dev ~]$ php-7.0 -r "var_dump(mt_rand(222,
> '99999999999999999999999'));"
>
> Warning: mt_rand() expects parameter 2 to be integer, string given in
> Command line code on line 1
> NULL
>
> This behavior is much better. I mean E_WARNING and return NULL from
> function is
> much easier than dealing with E_RECOVERBLE_ERROR.
>
> Strict mode may stay as it is, but shouldn't we have consistent behavior?
> Internal function raises E_WARNING for too large int while user function
> raises E_RECOVERBLE_ERROR
> does not make much sense.
>
> Regards,
>
> P.S.
> With strict_types=1, mt_rand() gives
>
> Fatal error: mt_rand() expects parameter 2 to be integer, string given in
> /home/yohgaki/t.php on line 3
>
>
> --
> 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

--089e016817e0f8e8b105160e579c--