sile / jsone

Erlang JSON library
MIT License
291 stars 72 forks source link

Sensible default handling for tuples #70

Open menih opened 2 years ago

menih commented 2 years ago

Consider the following

1> Tuple = {{key, value}, { key2, {key3, [value1, 2,3]}}}. {{key,value},{key2,{key3,[value1,2,3]}}}

Produces:

2> jsone:encode(Tuple). ** exception error: bad argument in function jsone_encode:value/4 called as jsone_encode:value({{key,value},{key2,{key3,[value1,2,3]}}}, [],<<>>, {encode_opt_v2,false,false,false, [{scientific,20}], {iso8601,0}, string,0,0,false,false,undefined}) in call from jsone:encode/2 (jsone.erl, line 382)

I think we should have a sensible default in these cases. Here is one suggestion:

{"key":"value", "key2, {"key3":["value1", 2,3]}}

How would one be able to pass on hints on how to handle certain conversion when default fails?

sile commented 2 years ago

You can use the map_unknown_value encoding option for this purpose.

The following code is an example:

tuple_to_assoc_list({K, V}) when is_atom(K) ->
    {ok, [{K,V}]};
tuple_to_assoc_list(T) when is_tuple(T) ->
    L = tuple_to_list(T),
    case lists:all(fun ({_, _}) -> true; (_) -> false end, L) of
        false -> error;
        true -> {ok, [{K, V} || {K, V} <- L]}
    end;
tuple_to_assoc_list(_) ->
    error.

%% > Tuple =  {{key, value}, { key2, {key3, [value1, 2,3]}}}.
%% > jsone:encode(Tuple, [{map_unknown_value, fun jsone:tuple_to_assoc_list/1}]).
%% <<"{\"key\":\"value\",\"key2\":{\"key3\":[\"value1\",2,3]}}">>
menih commented 2 years ago

I think we need to have a decent defaults, or somehow being able to initialize the library to have a defaults. Specifying encoding options for each encoding code is too much boiler plane in my opinion. If one does not line the default, they can always change it. Here is the main motivation - if you consider you'd want to encode any random term, without knowing anything about it, you'd want to the translation to ALWAYS pass, not matter what. This is especially relevant to logging.

sile commented 2 years ago

This is especially relevant to logging.

For this purpose, jsone:term_to_json_string/1 (introduced by #65) can be used I think. And it's the default value of map_unknown_value since v1.7.0. So, using the latest jsone, the example tuple can be encoded without errors.

1> Tuple =  {{key, value}, { key2, {key3, [value1, 2,3]}}}.
{{key,value},{key2,{key3,[value1,2,3]}}}
2> jsone:encode(Tuple).
<<"\"{{key,value},{key2,{key3,[value1,2,3]}}}\"">>
sile commented 2 years ago

An ugly point of jsone:term_to_json_string/1 is that it always converts unknown terms to binaries. But, IMO, it's too difficult to convert unknown tuples into nicer ones than binaries without any prior knowledge as tuples are widely used in Erlang for various purposes (of course, PRs are welcomed if you're interested in implementing the default converter).

menih commented 2 years ago

We should only convert the portions that are not translated. Not the entire term. I have to admit I'm not an erland expert to suggest a PR. Otherwise, I would have done so already.

On Fri, Nov 19, 2021, 6:37 PM Takeru Ohta @.***> wrote:

An ugly point of jsone:term_to_json_string/1 is that it always converts unknown terms to binaries. But, IMO, it's too difficult to convert unknown tuples into nicer ones than binaries without any prior knowledge as tuples are widely used in Erlang for various purposes (of course, PRs are welcomed if you're interested in implementing the default converter).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sile/jsone/issues/70#issuecomment-974579397, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2FAFKNQBD2QIZA7XRM733UM4CWTANCNFSM5INI3RMQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

sile commented 2 years ago

We should only convert the portions that are not translated.

I agree that it would be nice. But, again, that sounds very difficult to me.