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

Reply via email to