<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div>On Aug 26, 2014, at 2:30 PM, Ciprian Dorin Craciun <<a href="mailto:ciprian.craciun@gmail.com">ciprian.craciun@gmail.com</a>> wrote:<br><blockquote type="cite"><br> The reason that I wrote this email is because I have invested<br>quite some time in writing a "few" JSON utility functions (including<br>complex schema validation, destructuring, etc.) which heavily use and<br>extend the "mochi" variant. Based on this experience and a small<br>analysis I've done today, I concluded that EEP-0018 would be quite<br>cumbersome for expressing any kind of extension without a lot of<br>pattern-matching to catch the extensions. However by no mean do I<br>expect developers to change their libraries to suite such a usage, I<br>only wanted to provide a counter-argument to EEP-0018. Moreover, now<br>that Erlang has hash objects, hopefully these can be used to express<br>objects, and this problem would go away.<br><br> Hopefully I haven't offended anyone, (I apologize in advance,)<br> Ciprian.<br><br></blockquote><br>if i were to write jsx today i’d still allow serialization of `[{}]` to the empty object “{}” but i’d also probably allow `{[]}` also. i’d never deserialize json to a proplist though; maps only. i’ve been working on a small experimental attempt at a ‘modern’ json api here:<a href="https://github.com/talentdeficit/json">https://github.com/talentdeficit/json</a></div><br></body></html>