hi list,<br><br>whilst working on a native eep0018 implementation (<a href="http://github.com/pboy/eep0018">http://github.com/pboy/eep0018</a>) I came across some problems with EEP0018. The following is an excerpt from my README file, that states these issues:<br>
<br> ============================================================================================<br><br><div style="margin-left: 40px;">json_to_term/2 Options - Differences to EEP 18<br>==============================================<br>
<br>EEP0018 states<br><br>|       The {float,true} option says to convert all JSON numbers to<br>|       Erlang floats, even if they look like integers.<br>|       With this option, the result has type json(L, float()).<br>
|       <br>|       The {float,false} option says to convert integers to integers;<br>|       it is the default.<br>|       With this option, the result has type json(L, number()).<br>|       <br>|       The {label,binary} option says to convert all JSON strings<br>
|       to Erlang binaries, even if they are keys in key:value pairs.<br>|       With this option, the result has type json(binary(), N).<br>|       This is the default.<br>|       <br>|       The {label,atom} option says to convert keys to atoms if<br>
|       possible, leaving other strings as binaries.<br>|       With this option, the result has type json(json_label(), N).<br>|       <br>|       The {label,existing_atom} option says to convert keys to<br>|       atoms if the atoms already exist, leaving other keys as<br>
|       binaries.  All other strings remain binaries too.<br>|       With this option, the result has type json(json_label(), N).<br><br>Instead of that we implement the following options<br><br>{parse,object}(*) ...... Parse only Erlang objects and arrays, i.e. parsing "123" would fail.<br>
{parse,value}            Parse all Erlang values, i.e. parsing "123" would succeed.<br><br>{objects,eep0018} ... (*) JSON objects will be mapped as laid out in EEP0018, i.e.<br>                            {} -> [{}]<br>
                            {"a":"b","c":"d"} -> [{<<"a">>,<<"b">>},{<<"c">>,<<"d">>}]<br>
{objects,compat}          JSON objects will be mapped as in some other implementations, i.e. <br>                            {} -> {[]}<br>                            {"a":"b","c":"d"} -> {[{<<"a">>,<<"b">>},{<<"c">>,<<"d">>}]}<br>
<br>{labels,binary} ... (*) Labels will be mapped as binaries, i.e.<br>                          {"a":"b","c":"d"} -> {[{<<"a">>,<<"b">>},{<<"c">>,<<"d">>}]}<br>
{labels,atom}           Labels will be mapped as binaries, i.e.<br>                          {"a":"b","c":"d"} -> {[{a,<<"b">>},{c,<<"d">>}]}<br>
                        Use this option only if you know that there is a limited range of<br>                        possible labels and that these labels can be converted to atoms.<br><br>                        The {labels,existing_atom} option is not implemented, because <br>
                          a) it runs quite slow, and<br>                          b) the result of such an operation is unpredictable.<br><br>{number,exact} ... (*) Numbers are parsed exactly as they are in the JSON source code, i.e.<br>
                       a JSON integer will be mapped as an Erlang integer, and a JSON float<br>                       will be mapped as an Erlang float, in the precision supported by the<br>                       current OTP runtime.<br>
{number,number}        Numbers are parsed exactly as they are in the JSON source code, i.e.<br>                       a JSON integer will be mapped as an Erlang integer, and a JSON float<br>                       will be mapped as an Erlang float, in the precision supported by the<br>
                       C runtime and ei libraries, eg. signed 32-bit for integers and 64 bit <br>                       floating points.<br>{number,float}         All numbers are parsed as an Erlang float, in the precision supported<br>
                       by the C runtime (eg. 64 bit).<br><br>Performance considerations<br>==========================<br><br>Some of these options have a huge performance impact, as they are implemented on the Erlang side<br>
and so require a two-step parsing process (one round in the driver and one extra round in Erlang):<br><br> * {number,exact} is implemented by transmitting the number value as a string<br> * {objects,compat} is currently implemented in Erlang. A final implementation -<br>
   after everyone agreed upon the Erlang mapping of JSON objects, would of<br>   course be done in C. <br></div><br>============================================================================================<br>
<br>/eno<br><br>-- <br>====================================================================<br>A wee piece of ruby every monday: <a href="http://1rad.wordpress.com/">http://1rad.wordpress.com/</a><br><br><br><br>