Loading ...
Sorry, an error occurred while loading the content.

Operator-overloaded JSON API: best way to handle arrays?

Expand Messages
  • Rob Meijer
    A while ago I wrote the JsonMe++ wrapper library. Currently a wrapper for the parsing part of the glib JSON C library. https://github.com/pibara/jsonme--
    Message 1 of 4 , Feb 20, 2012
    • 0 Attachment
      A while ago I wrote the JsonMe++ wrapper library. Currently a wrapper
      for the parsing part of the glib JSON C library.

      https://github.com/pibara/jsonme--

      JsonMe++ provides an API that heavily uses operator overloading, cast
      operators and value semantic proxies to provide
      a bit of a scripting language like API for parsing JSON.

      Now I would like to continue working on JsonMe++ by expanding the API
      with the possibility of also creating JSON
      rather than just parsing it. Handling objects seems quite simple and
      natural to do simply by adding some assignment
      operators to the API.

      Handling arrays however has got me a bit confused. Do I stick to an
      API with as little as possible 'named', node level methods?
      It does seem to have a lot of merit to keep the node API without named
      methods, but this will require me to handle
      sparse arrays, what might or might not be a good idea.

      Basically I could make the API work like:

      jsondoc["foo"][1]["bar"] = "harhar";

      And let, if jsondoc was empty still, create a new json object with a
      foo memeber that is a sparse array with an empty index 0 element
      and an object index 1 element that has a "bar" member with value "harhar".

      Alternatively I could make the API so that the above would need to be
      expressed as:

      jsondoc["foo"].append();
      jsondoc["foo"].append()["bar"] = "harhar"

      I don't know if one of these would be better, or if there would be a
      third alternative that would be more suitable.
      I would be very interested in learning what others think.

      Rob
    • Fernando Ribeiro
      I d say you may want not to abuse on overloading, which may make you API harder to use, even though it first seems to be doing the opposite. Regards. ...
      Message 2 of 4 , Feb 20, 2012
      • 0 Attachment
        I'd say you may want not to abuse on overloading, which may make you API
        harder to use, even though it first seems to be doing the opposite. Regards.
        On Feb 20, 2012 8:09 AM, "Rob Meijer" <pibara@...> wrote:

        > **
        >
        >
        > A while ago I wrote the JsonMe++ wrapper library. Currently a wrapper
        > for the parsing part of the glib JSON C library.
        >
        > https://github.com/pibara/jsonme--
        >
        > JsonMe++ provides an API that heavily uses operator overloading, cast
        > operators and value semantic proxies to provide
        > a bit of a scripting language like API for parsing JSON.
        >
        > Now I would like to continue working on JsonMe++ by expanding the API
        > with the possibility of also creating JSON
        > rather than just parsing it. Handling objects seems quite simple and
        > natural to do simply by adding some assignment
        > operators to the API.
        >
        > Handling arrays however has got me a bit confused. Do I stick to an
        > API with as little as possible 'named', node level methods?
        > It does seem to have a lot of merit to keep the node API without named
        > methods, but this will require me to handle
        > sparse arrays, what might or might not be a good idea.
        >
        > Basically I could make the API work like:
        >
        > jsondoc["foo"][1]["bar"] = "harhar";
        >
        > And let, if jsondoc was empty still, create a new json object with a
        > foo memeber that is a sparse array with an empty index 0 element
        > and an object index 1 element that has a "bar" member with value "harhar".
        >
        > Alternatively I could make the API so that the above would need to be
        > expressed as:
        >
        > jsondoc["foo"].append();
        > jsondoc["foo"].append()["bar"] = "harhar"
        >
        > I don't know if one of these would be better, or if there would be a
        > third alternative that would be more suitable.
        > I would be very interested in learning what others think.
        >
        > Rob
        >
        >


        [Non-text portions of this message have been removed]
      • wjosdejong
        Maybe it is useful to have a look at how this is implemented in Javascript, where JSON originally comes from. In Javascript you really need to define arrays
        Message 3 of 4 , Feb 20, 2012
        • 0 Attachment
          Maybe it is useful to have a look at how this is implemented in Javascript, where JSON originally comes from. In Javascript you really need to define arrays and objects, there is no implicit creation of arrays/objects.

          I think implicitly creating arrays is quite tricky. For example, if you look at
          jsondoc["foo"][1]["bar"] = "harhar";
          the type of the key (String or Number) determines if an object or an array will be created...

          I think it is better force explicit creation of arrays and objects, that will not lead to misconceptions.

          Jos


          --- In json@yahoogroups.com, Rob Meijer <pibara@...> wrote:
          >
          > A while ago I wrote the JsonMe++ wrapper library. Currently a wrapper
          > for the parsing part of the glib JSON C library.
          >
          > https://github.com/pibara/jsonme--
          >
          > JsonMe++ provides an API that heavily uses operator overloading, cast
          > operators and value semantic proxies to provide
          > a bit of a scripting language like API for parsing JSON.
          >
          > Now I would like to continue working on JsonMe++ by expanding the API
          > with the possibility of also creating JSON
          > rather than just parsing it. Handling objects seems quite simple and
          > natural to do simply by adding some assignment
          > operators to the API.
          >
          > Handling arrays however has got me a bit confused. Do I stick to an
          > API with as little as possible 'named', node level methods?
          > It does seem to have a lot of merit to keep the node API without named
          > methods, but this will require me to handle
          > sparse arrays, what might or might not be a good idea.
          >
          > Basically I could make the API work like:
          >
          > jsondoc["foo"][1]["bar"] = "harhar";
          >
          > And let, if jsondoc was empty still, create a new json object with a
          > foo memeber that is a sparse array with an empty index 0 element
          > and an object index 1 element that has a "bar" member with value "harhar".
          >
          > Alternatively I could make the API so that the above would need to be
          > expressed as:
          >
          > jsondoc["foo"].append();
          > jsondoc["foo"].append()["bar"] = "harhar"
          >
          > I don't know if one of these would be better, or if there would be a
          > third alternative that would be more suitable.
          > I would be very interested in learning what others think.
          >
          > Rob
          >
        • John Cowan
          ... On the contrary, I think this is a very good idea. It s called autovivification in Perl, and is very convenient. It is particularly nice that the
          Message 4 of 4 , Feb 20, 2012
          • 0 Attachment
            wjosdejong scripsit:

            > I think implicitly creating arrays is quite tricky. For example,
            > if you look at
            > jsondoc["foo"][1]["bar"] = "harhar";
            > the type of the key (String or Number) determines if an object or an
            > array will be created...

            On the contrary, I think this is a very good idea. It's called
            "autovivification" in Perl, and is very convenient. It is particularly
            nice that the static type of the key determines what sort of JSON object
            to make.

            --
            John Cowan cowan@... http://ccil.org/~cowan
            This great college [Trinity], of this ancient university [Cambridge],
            has seen some strange sights. It has seen Wordsworth drunk and Porson
            sober. And here am I, a better poet than Porson, and a better scholar
            than Wordsworth, somewhere betwixt and between. --A.E. Housman
          Your message has been successfully submitted and would be delivered to recipients shortly.