Hi Pierre,
On Mon, Mar 30, 2015 at 11:42 AM, Pierre Joye <pierre....@gmail.com> wrote:
> On Mon, Mar 30, 2015 at 9:14 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> > Hi Pierre,
> >
> > On Mon, Mar 30, 2015 at 10:54 AM, Pierre Joye <pierre....@gmail.com>
> wrote:
> >>
> >> Same effects but totally unrelated topics. All functions dealing with
> >> large external numbers had the same issues, since ever. It has nothing
> >> to do with STH.
> >
> >
> > Yes, it is.
> > Developers make casting mistakes like this even when they are used to
> strict
> > typing.
>
> I understand and this is why I said it is the same symptom. But JSON
> or any other external data decoding has nothing to do with STH. It
> would be nice to do not clutter this discussion with yet another STH
> argument :)
As you know, I'm an very unhappy person with the accepted RFC :)
Since Zeev closed the vote before the end date, I think we may have a little
chance to improve weak mode scalar type hint. i.e. Use Zeev's RFC for weak
mode.
Anyway, similar issue is not only external but also PHP internal.
For example,
[yohgaki@dev php-src]$ ./php-bin -r 'var_dump(["999999999999999999999"=>1,
999999999999999999999=>1]);'
array(2) {
["999999999999999999999"]=>
int(1)
[3875820019684212736]=>
int(1)
}
Library that deals with array should use "string" key data type to have
correct key for
any number even when library expects integer keys. i.e. The library must
have "string" type hint for integer key to achieve correct behavior.
Database, JSON and array are good examples of confusions. Smart developers
will use "string" type hints for these, while less experienced developers
will use
"int/float" type hints for these. When users have to use both of them,
users are
forced to casting variable between "string" and "int/float". This makes
impossible
to write "correct" code. This JSON bug is a proof that this will happen.
I just don't see the point to introduce new feature that makes impossible
to write
correct code while there is good solution. Fortunately, we still have time
to address
this.
Regards,
P.S. Does anyone have alternative ideas for this?
--
Yasuo Ohgaki
yohg...@ohgaki.net
