Re: [RFC] Enum proposal (yet another)
| From: | Ángel González | Date: | Mon, 27 Feb 2012 23:21:22 +0000 |
| Subject: | Re: [RFC] Enum proposal (yet another) | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-58216@lists.php.net to get a copy of this message | ||
On 27/02/12 19:22, Richard Lynch wrote:
>>> I'm not so sure about that. In a well-written web application, you
>>> would
>>> typically convert them on the first layer, when receiving from the
>>> web.
>>> On next usages, your int variables are usually ints already.
> Afraid not.
>
> It turns out that PHP, on 32-bit hardware, converting large BIGINT
> using (int) $ID ends up as a negative number, and then when you pass
> it in to the database if a string query, you get a negative ID, not at
> all what was intended.
>
> (Been there, done that, got burned)
>
> At least, that's been my experience with some versions of PHP and some
> database drivers.
>
> So at least the database IDs have to remain as strings, if you are
> using BIGINT.
>
> You could, of course, only convert the values known to be in range of
> PHPs positive integers, and leave the others as strings.
>
> This is just a simple example of how the super strict typing simply
> doesn't work out too well in PHP.
That's a good example from experience.
Although if you want to keep ids as strings, you can simply keep them as a
string type.
I was thinking on input coming from a web browser, btw.