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

Re: [json] Operator-overloaded JSON API: best way to handle arrays?

Expand Messages
  • 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 1 of 4 , Feb 20 5:31 AM
    • 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 2 of 4 , Feb 20 10:44 AM
      • 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 3 of 4 , Feb 20 10:53 AM
        • 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.