lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Wed, Sep 8, 2010 at 7:02 AM, Brian Maher <> wrote:
> Thanks for posting the comparison wiki page.  I notice the "protection
> against bloated arrays when encoding" section.  Does this mean that
> people desire for this:
>  {[1000] = "harhar"}
> To be encoded as this?
>  {"1000":"harhar"}
> Instead of encoding it as:
>  [null,null,...,"harhar"]

Personally, I don't like that sort of behavior. What I did in my
Jansson binding was disallow encoding of mixed tables (with both
numeric and non-numeric keys), and I added json.array() and
json.object() to force encoding a table to a specific one. {} is
ambiguous too, so you need to use json.array() and json.object() if
you want an empty one of either. I also added json.null, which encodes
a JSON null value.

With those tools, you can do json.encode(json.object {[1000] =
"harhar"}) to get your JSON object result, and
json.encode(json.array{json.null, json.null ... [1000] = "harhar"}) to
get the JSON array result. (Though in retrospect, maybe json.array{}
shouldn't need all of those json.null's, since you're forcing it
instead of passing it straight to json.encode after all.)

I'm the only one to have used this binding, so I don't know if this is
a generally good way to do it, but I like it a lot. I should really
just toss it onto a GitHub repo...

> Another interesting comparison is if the various implementations allow
> custom "serializers" that allow userdata or lua "objects" to specify
> how the lua implementation can be translated into JSON.  The lua-json
> implementation supports this sort of custom "serialization" via the
> __gen_json meta-method.

...That's a fantastic idea.