On Mon, Mar 30, 2015 at 9:04 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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? > > Please can this be discussed in a new thread? This thread is just about adding a new option to json ext. Cheers Jakub