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

__jsonclass__ hinting

Expand Messages
  • meyer_jon
    (longish, sorry if this has come up before, I didn t see it) Looking at the JSON-RPC spec, it offers a way to hint at types in JSON messages:
    Message 1 of 1 , Jul 24, 2006
      (longish, sorry if this has come up before, I didn't see it)

      Looking at the JSON-RPC spec, it offers a way to hint at types in JSON

      {"__jsonclass__":["constructor", [param1,...]], "prop1": ...}

      This pattern supports encoding of complex typed objects in a JSON
      message e.g.

      {"__jsonclass__":["Date", "Dec 25, 1995"] }

      {"__jsonclass__":["Person", "Joe", "Smith", 56] }

      Its a neat trick.

      And JSON itself *requires* a standard hinting convention. Any JSON
      processor written in a typed language (C#, Java etc) needs to handle
      type conversions. Today every processor out there is creating its own
      ad-hoc hinting convention. These are unlikely to play well together.

      With a standard type hinting mechanism we can write "validators"
      (everyone groan!) to check the types of a JSON message before
      processing. Yay for type hinting!

      However, __jsonclass__ goes a step too far, and so only muddies the
      water further.

      Consider our lowly Date. According to the JSON RPC spec all of the
      following could be legal:

      {"__jsonclass__":["Date", "Mon, 25 Dec 1995 13:30:00 GMT"] }
      {"__jsonclass__":["Date", "Dec 25, 1995"] }
      {"__jsonclass__":["Date", 191121232] }
      {"__jsonclass__":["Date", 1956, 1, 31] }

      Sadly, none of those give us our beloved ISO 8601. For that we'll need
      something else, possibly:

      {"__jsonclass__":["MyIsoDateClass", "2006-12-15T19:15:00Z"] }

      So we have just as many ways to encode a date in JSON as before
      __jsonclass__, except we now have more complex format!

      The flaw is this: __jsonclass__ aims to solve one problem (tagging
      objects with type hints -- a good thing), but as a side effect
      introduces an additional untyped data collection (the constructor
      args). So then you are back to typing the values in the constructor
      args... its pushed the problem further down, adding complexity.

      An alternative is the "what the heck, lets throw constructors into
      JSON" solution. It goes like this:

      "birthDate": new Date("Mon, 25 Dec 1995 13:30:00 GMT"),

      The main advantage of this over __jsonclass__ is that you can directly
      eval the message in JavaScript. The __jsonclass__ approach requires a
      second pass over the data to execute constructors. Pretty compelling
      given browser perf limitations. If we must have constructors I prefer
      this latter solution to __jsonclass__.

      However, neither approach get us closer to type hinting mechanism that
      is easy for non-JavaScript languges.

      What shines most about JSON is its simplicity. So type hinting
      deserves a similarly simple solution. I propose a simple hint (e.g.
      __jstype) which only carries type information. e.g.

      "__jstype": "Person",
      "firstName": "Joe",
      "lastName": "Smith",
      "age": 23,

      For dates and other core value types, we could even (gasp) agree on
      some standard __jstype hints:

      "__jstype": "dateTime",
      "value": "2006-12-15T19:15:00Z",

      Yes, you still have to process the data to convert it to a Date (no
      different from the __jsonclass__ approach there).

      But the main point is that __jstype does not mix type information in
      with the data - it doesn't introduce a new untyped collection that
      processors must wrangle with.

      For now, I'll probably use the closest I can get __jsonclass__, namely:

      "firstName": "Joe",
      "lastName": "Smith",
      "age": 23,

      There's an extra array per object during processing, but it conforms
      to the spec.


    Your message has been successfully submitted and would be delivered to recipients shortly.