« Return to Thread: json_to_term EEP
Re: json_to_term EEP
by Hynek Vychodil
::
Rate this Message:
On Tue, Jul 29, 2008 at 4:07 PM, Robert Virding <rvirding@...> wrote:
*I am no expert.* You are joking.
So on topic:
JSON: {"key":"value", "key2":{}, "key3":[{}, 3.14 , "val", true], "key4": {"a":false, "b":2} }
(B): {[
{<<"key">>, <<"value">>},
{<<"key2">>, {[]}},
{<<"key3", [{[]}, 3.14, <<"val">>, true]},
{<<"key4">>, {[{<<"a">>, false},{<<"b">>, 2}]}}
]}
(C): [
{<<"key">>, <<"value">>},
{<<"key2">>, [{}]},
{<<"key3", [[{}], 3.14, <<"val">>, true]},
{<<"key4">>, [{<<"a">>, false},{<<"b">>, 2}]}
]
(One can use it as simple test case ;-) )
I don't know why (B) version should be better than (C). It's true that (B) have minimal overhead and (C) have a little bit (a really little) more complicate object detection, but in both variants object and list can be determined exactly and in both in function/case guard expression. Notice key2, key3 and key4 values.
Result:
(B) - one structure level for each object more - no problem in Erlang
(C) - first element type check "more" - no problem in Erlang
It's fifty fifty in technically manner and only personal preference rules. (One more structure level is worse in my feeling, but ...)
I argue unification, so transforming all to atom is insecure and result is don't use this way at all.
Aside non-uniformity of list_to_existing_atom way, there is performance drawback too. For each key you must call list_to_existing_atom(binary_to_list(X)) and binary_to_list causes GC pressure in this usage. I would not have use this variant, too.
All is binary is best for me.
P.S.: Why non-uniform is problem. One can argue, it looks nicer. OK. One can argue, binary->atom transformation is done only for exists atoms and all atoms which used in comparisons are exists. BAD, imagine for example store Erlang term for long time or send to other nodes ... It *can* complicate think, so avoid it if you can and we *can*. I think, it is dangerous.
You will have to forgive but I am now going to do something which I hate when others do it: comment without really knowing much about the topic. :-)Why not just use option (B) and have the empty object as {[]}? It is always consistent and the empty object is easily from the empty list and empty string. I don't see having the extra tuple should cause any problems, but then again I am no expert.
*I am no expert.* You are joking.
So on topic:
JSON: {"key":"value", "key2":{}, "key3":[{}, 3.14 , "val", true], "key4": {"a":false, "b":2} }
(B): {[
{<<"key">>, <<"value">>},
{<<"key2">>, {[]}},
{<<"key3", [{[]}, 3.14, <<"val">>, true]},
{<<"key4">>, {[{<<"a">>, false},{<<"b">>, 2}]}}
]}
(C): [
{<<"key">>, <<"value">>},
{<<"key2">>, [{}]},
{<<"key3", [[{}], 3.14, <<"val">>, true]},
{<<"key4">>, [{<<"a">>, false},{<<"b">>, 2}]}
]
(One can use it as simple test case ;-) )
I don't know why (B) version should be better than (C). It's true that (B) have minimal overhead and (C) have a little bit (a really little) more complicate object detection, but in both variants object and list can be determined exactly and in both in function/case guard expression. Notice key2, key3 and key4 values.
Result:
(B) - one structure level for each object more - no problem in Erlang
(C) - first element type check "more" - no problem in Erlang
It's fifty fifty in technically manner and only personal preference rules. (One more structure level is worse in my feeling, but ...)
I would prefer to always have strings in *one* format and not special case keys with atoms sometimes. Otherwise to be certain you would have to match both atom and binary to find key. Unless you *always* use atoms for keys, which could easily explode.
I argue unification, so transforming all to atom is insecure and result is don't use this way at all.
Aside non-uniformity of list_to_existing_atom way, there is performance drawback too. For each key you must call list_to_existing_atom(binary_to_list(X)) and binary_to_list causes GC pressure in this usage. I would not have use this variant, too.
All is binary is best for me.
P.S.: Why non-uniform is problem. One can argue, it looks nicer. OK. One can argue, binary->atom transformation is done only for exists atoms and all atoms which used in comparisons are exists. BAD, imagine for example store Erlang term for long time or send to other nodes ... It *can* complicate think, so avoid it if you can and we *can*. I think, it is dangerous.
Robert2008/7/29 Hynek Vychodil <vychodil.hynek@...>On Tue, Jul 29, 2008 at 3:13 AM, Richard A. O'Keefe <ok@...> wrote:
On 29 Jul 2008, at 9:51 am, Paulo Sérgio Almeida wrote:This is in fact what I originally proposed,
> I think there is no doubt that lists will be more useful than
> tuples. There is, however another option, that I have been using in
> a json parser I wrote:
>
> (C) an object is simply a proplist, i.e. a list of tuples.
the tricky point being that {} is a legal empty object in JSON,
and we can't map that to [] because that's the representation
for the empty sequence [].
(O) Original proposal: {} => {}, other objects => list of pairs
(A) Armstrong version: object => tuple of pairs, no exceptions.
(B) Object => {list of pairs}.
(C) Almeida proposal: as (O) but {} => [{}].
The arguments for usability of the result in Erlang are the
arguments that originally had me proposing (O).
However, I note that nothing stops us providing a range of
handy-dandy functions that work on tuples of pairs.
%(O)
is_object({}) -> true;
is_object([{_,_}|_]) -> true;
is_object(_) -> false.
%(A)
is_object(T) -> is_tuple(T).
%(B)
is_object({T}) -> is_list(T).is_object({T}) -> is_list(T);
is_object(_) -> false. % avoid exception
%(C)
is_object([T|_]) -> is_tuple(T);
is_object(_) -> false.
It's rather annoying to be so bothered about empty objects;
do they occur in practical JSON? Proposal (C) seems neat enough;
the main problem is fitting the results with @type.
(C) seems good for me too, because proplist works fine with it.
> proplists:get_bool(a, [{}]).
false
> proplists:get_bool(a, [{a, true}]).
true
> proplists:get_value(a, [{a, true}]).
true
> proplists:get_value(a, [{a, heh}]).
heh
> proplists:get_value(a, [{}]).
undefined
atom is used only for simplicity, but works with binaries too. (JSON's boolean should be true/false atom of course I assume.)
--
If stupidity were a crime, who'd 'scape hanging?
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions
--
--Hynek (Pichi) Vychodil
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions
--
--Hynek (Pichi) Vychodil
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions
« Return to Thread: json_to_term EEP
| Free embeddable forum powered by Nabble | Forum Help |
