[erlang-questions] No JSON/MAPS interoperability in 17.0?

[Tony Rogvall]

On 8 mar 2014, at 14:47, Pierre Fenoll <pierrefenoll@REDACTED> wrote:

> Let's not forget though that most languages implementation of JSON uses hash tables.
> Before 17.0, the JSON mapping used lists; taking lookup linear time.
> Maps have a lookup time of O(log n).
> That's still not O(1)…
> 
The current map implementation suggest that you should not use it for big maps yet.
Say less than 10 elements or so. Guess what? that could be thought of as O(1) :-)

/Tony

> 
> Cheers,
> -- 
> Pierre Fenoll
> 
> 
> 
> On 8 March 2014 14:42, Carsten Bormann <cabo@REDACTED> wrote:
> It is true that different applications may need different mappings of the JSON data model into the data model of the specific application, but the following is not a valid reason:
> 
> On 08 Mar 2014, at 13:14, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
> 
> > And to make things worse, there are small fluctuations in the "standard" which make it hard to create proper support. Adding a `json` module to the standard library is asking for jumping into this minefield.
> 
> The “standard” has been stable since RFC 4627, which was published in July 2006.
> Since, ECMA TC39 (the committee for changing JavaScript) has decided to allow top-level numbers, primitives (false, true, null), and strings; the IETF has reluctantly followed this change and published RFC 7159 with that change.
> 
> Apart from the question whether one should accept top-level numbers/primitives/strings (and it is easy for an application to follow the Postel principle here: be liberal in what you accept and conservative in what you send), there has been no “fluctuation” in JSON.
> 
> With the acceptance of UTF-8 strings (“binaries”) into the Erlang world, there is a straightforward mapping of JSON data into the Erlang model.
> Mapping back may require a bit more application knowledge (e.g., how do you encode non-JSON concepts such as atoms?), but a basic mapping can easily be part of the standard library, certainly easier than for ASN.1 or XML.
> 
> Grüße, Carsten
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140309/601e0a99/attachment.htm>