Erlang R17 has maps

[edescourtis]

Please provide some way to convert json objects into Erlang maps directly.

[talentdeficit]

i'll have something in the next week or two

the implementation is pretty straight forward i'm just trying to figure out an interface.

what i'm leaning towards now is:

$ jsx:to_list(<<"{}">>).
[{}]
$ jsx:to_term(<<"{}">>).
#{}
$ jsx:decode(<<"{}">>).
#{}
$ jsx:decode(<<"{}">>, [{objects, proplist}]).
[{}]
$ jsx:decode(<<"{}">>, [{objects, map}]).
#{}

[ransomr]

Please consider not changing the default output of jsx:decode, as it will break compatibility. For example I use jsx:decode in the erlcloud DynamoDB client. If someone were to upgrade to a new version of jsx that changed the output from a proplist to a map it would completely break erlcloud DynamoDB client.

[talentdeficit]

the other option is adding parse/stringify methods that work on maps (altho stringify will likely just be an alias for encode. i can't forsee any issues with that?)

[edescourtis]

I agree with this. However having to type extra stuff every time might not
be a good idea. Instead you should provide an updated interface along with
the old one.

Consider something like jsx_ng:decode(<<"{}">>) -> #{} and keeping the old
interface as is.

That way backward compatibility can be preserved.

On Wed, Feb 5, 2014 at 10:27 AM, Ransom Richardson <notifications@github.com

wrote:

Please consider not changing the default output of jsx:decode, as it will
break compatibility. For example I use jsx:decode in the erlcloud DynamoDB
client. If someone were to upgrade to a new version of jsx that changed the
output from a proplist to a map it would completely break erlcloud DynamoDB
client.

Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-34188404
.

[ransomr]

I'm not sure I fully understand the parse/stringify proposal. What is important for compat is that the output of all existing methods doesn't change and that all arguments that are currently supported continue to be supported.

So I'm not aware of any good options other than leaving existing interface and adding a new one. Any of jsx:decode2, jsx2:decode, jsx_ng:decode, or if you prefer shorter jsx:dec, should work. Or you could do as you propose and have an {objects, map} option as long as the default stays proplist, but since map will be the preferred output going forward, would be too bad to have to add that every call.

[talentdeficit]

decode would remain exactly as it is now (barring being slightly more permissive in the input it accepts. output should remain unchanged for anything it currently accepts).

parse would work as decode except instead of returning proplists where appropriate it would return maps. so:

$ jsx:decode(<<"{}">>).
[{}]
$ jsx:parse(<<"{}">>).
#{}

[ransomr]

Perfect, sorry I misunderstood. parse would work fine.

[edescourtis]

It would work but might confuse people 2 or 3 years down the road.

On Wed, Feb 5, 2014 at 5:31 PM, Ransom Richardson
notifications@github.comwrote:

Perfect, sorry I misunderstood. parse would work fine.

Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-34263503
.

[talentdeficit]

encoding support is now live in the maps branch

still thinking about how best to deal with the interface issues with supporting maps and proplists at the same time

[talentdeficit]

for 2.0 i've decided to allow transparent encoding of maps to json but to pass on supporting decoding to maps for now. i'm still not convinced they are a good match for json. i will probably put up an application that extends jsx and replaces proplists with maps for those that disagree, but i doubt json -> maps will be coming to jsx core anytime soon

[edescourtis]

@talentdeficit Acceptable compromise. Good work!

[talentdeficit]

see https://github.com/talentdeficit/jsxn for a wrapper around jsx that decodes to maps

[edescourtis]

@talentdeficit You are amazing! Thanks!