[erlang-questions] json_to_term EEP

[Hynek Vychodil]

On Tue, Jul 29, 2008 at 4:07 PM, Robert Virding <rvirding@REDACTED> wrote:

> 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.


> Robert
>
> 2008/7/29 Hynek Vychodil <vychodil.hynek@REDACTED>
>
>
>>
>> On Tue, Jul 29, 2008 at 3:13 AM, Richard A. O'Keefe <ok@REDACTED>wrote:
>>
>>> On 29 Jul 2008, at 9:51 am, Paulo Sérgio Almeida wrote:
>>> > 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 in fact what I originally proposed,
>>> 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@REDACTED
>>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>>
>>
>>
>>
>> --
>> --Hynek (Pichi) Vychodil
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
>
>


-- 
--Hynek (Pichi) Vychodil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080729/60fda660/attachment.htm>