[erlang-questions] json_to_term EEP

[Robert Virding]

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080729/358b97fe/attachment.htm>