<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Jul 29, 2008 at 4:07 PM, Robert Virding <span dir="ltr"><<a href="mailto:rvirding@gmail.com">rvirding@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">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. :-)<div><br></div><div>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.</div>
</div></blockquote><div><br>*I am no expert.* You are joking.<br><br>So on topic:<br><br>JSON: {"key":"value", "key2":{}, "key3":[{}, 3.14 , "val", true], "key4": {"a":false, "b":2} }<br>
<br>(B): {[<br> {<<"key">>, <<"value">>},<br> {<<"key2">>, {[]}},<br> {<<"key3", [{[]}, 3.14, <<"val">>, true]},<br>
{<<"key4">>, {[{<<"a">>, false},{<<"b">>, 2}]}}<br> ]}<br><br>(C): [<br>
{<<"key">>, <<"value">>},<br>
{<<"key2">>, [{}]},<br>
{<<"key3", [[{}], 3.14, <<"val">>, true]},<br>
{<<"key4">>, [{<<"a">>, false},{<<"b">>, 2}]}<br>
]<br><br>(One can use it as simple test case ;-) )<br>
<br>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.<br>
<br>Result:<br>(B) - one structure level for each object more - no problem in Erlang<br>(C) - first element type check "more" - no problem in Erlang<br>It's fifty fifty in technically manner and only personal preference rules. (One more structure level is worse in my feeling, but ...)<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div></div>
<div><br></div><div>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.</div>
</div></blockquote><div><br>I argue unification, so transforming all to atom is insecure and result is don't use this way at all.<br>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.<br>
All is binary is best for me.<br><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div dir="ltr"><div></div>
<div><br></div><div>Robert<br><br><div class="gmail_quote">2008/7/29 Hynek Vychodil <span dir="ltr"><<a href="mailto:vychodil.hynek@gmail.com" target="_blank">vychodil.hynek@gmail.com</a>></span><div><div></div><div class="Wj3C7c">
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><br><br><div class="gmail_quote"><div><div></div><div>On Tue, Jul 29, 2008 at 3:13 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On 29 Jul 2008, at 9:51 am, Paulo Sérgio Almeida wrote:<br>
> I think there is no doubt that lists will be more useful than<br>
> tuples. There is, however another option, that I have been using in<br>
> a json parser I wrote:<br>
><br>
> (C) an object is simply a proplist, i.e. a list of tuples.<br>
<br>
</div>This is in fact what I originally proposed,<br>
the tricky point being that {} is a legal empty object in JSON,<br>
and we can't map that to [] because that's the representation<br>
for the empty sequence [].<br>
<br>
(O) Original proposal: {} => {}, other objects => list of pairs<br>
(A) Armstrong version: object => tuple of pairs, no exceptions.<br>
(B) Object => {list of pairs}.<br>
(C) Almeida proposal: as (O) but {} => [{}].<br>
<br>
The arguments for usability of the result in Erlang are the<br>
arguments that originally had me proposing (O).<br>
<br>
However, I note that nothing stops us providing a range of<br>
handy-dandy functions that work on tuples of pairs.<br>
<br>
%(O)<br>
is_object({}) -> true;<br>
is_object([{_,_}|_]) -> true;<br>
is_object(_) -> false.<br>
<br>
%(A)<br>
is_object(T) -> is_tuple(T).<br>
<br>
%(B)<br>
is_object({T}) -> is_list(T).</blockquote></div></div><div>is_object({T}) -> is_list(T);<br>is_object(_) -> false. % avoid exception<br></div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
%(C)<br>
is_object([T|_]) -> is_tuple(T);<br>
is_object(_) -> false.<br>
<br>
It's rather annoying to be so bothered about empty objects;<br>
do they occur in practical JSON? Proposal (C) seems neat enough;<br>
the main problem is fitting the results with @type.</blockquote></div><div><br>(C) seems good for me too, because proplist works fine with it.<br><br>> proplists:get_bool(a, [{}]).<br>false<br>> proplists:get_bool(a, [{a, true}]).<br>
true<br>> proplists:get_value(a, [{a, true}]).<br>true<br>> proplists:get_value(a, [{a, heh}]).<br>heh<br>> proplists:get_value(a, [{}]).<br>undefined<br><br>atom is used only for simplicity, but works with binaries too. (JSON's boolean should be true/false atom of course I assume.)<br>
</div><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
--<br>
If stupidity were a crime, who'd 'scape hanging?<br>
</font><div><div></div><div><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br>
</div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>--Hynek (Pichi) Vychodil<br>
</div>