[erlang-questions] json_to_term EEP
Paulo Sérgio Almeida
psa@REDACTED
Mon Jul 28 23:51:23 CEST 2008
Hi,
Chris Anderson wrote:
> the two options in Erlang are:
>
> Tuple of tuples (A): {{<<"key">>, <<"value">>},{<<"key2">>, <<"value2">>}}
>
> or
>
> Tuple containing a list of tuples (B): {[{<<"key">>,
> <<"value">>},{<<"key2">>, <<"value2">>}]}
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.
This is what one really wants to have in erlang. The difference to
option (B) is that while if a single object is decoded it is easy to
discard the outer {}, when objects are used inside other structures that
is not the case anymore, and (C) will result in a greater chance of
allowing a decoded structure to be stored as is with no post-processing
in a useful erlang structure.
The only problem (C) poses is distinguishing the empty object from an
empty array. My solution (which I am almost happy about) is to represent
the empty object as [{}]. This way:
- objects can be distinguished from arrays, e.g. by the following function:
is_object(O=[T|_]) when is_tuple(T) -> true;
is_object(_) -> false.
- we can use objects as proplists, use functions like lists:keysearch or
list comprehensions like
Keys = [V || {V,_} <- Object]
which will work even for the special empty object [{}].
Anyway, the empty object is not a common case (at least for my
purposes), and the advantages of being able to store nested objects in
the most pleasant way is something that should make one consider option (C).
As others have said, I also do not consider option (A) useful.
Regards,
Paulo
P.S. Given the sudden interest in json, I will describe the options I
took in my parser and make it available in a subsequent post, to further
discussion.
More information about the erlang-questions
mailing list