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 <yohg...@ohgaki.net> wrote: > Hi Walter, > > On Tue, May 12, 2015 at 11:25 AM, Walter Parker <walt...@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 > yohg...@ohgaki.net > -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
