Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86209
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAMPTd_Ct6vScEChavHgeRScquCFYby80GzbPtze4sGofmzFwgw@mail.gmail.com>
References: <CAGa2bXaFnkU7hqR56kGkWqbrc8KivGEjUCXLi=5cJ5wr7MCq4Q@mail.gmail.com>
 <CAMPTd_Ct6vScEChavHgeRScquCFYby80GzbPtze4sGofmzFwgw@mail.gmail.com>
Date: Thu, 14 May 2015 16:16:36 +0900
Message-ID: <CAGa2bXbECPLnScF3wZeUDJPr=YP8V2vOQMEdXVP53HT=xxvcTw@mail.gmail.com>
To: Walter Parker <walterp@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e015368627b83b405160584ad
Subject: Re: [PHP-DEV] is_digits() and digits type
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e015368627b83b405160584ad
Content-Type: text/plain; charset=UTF-8

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

--089e015368627b83b405160584ad--