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

Re: RE : [json] __jsonclass__ hinting

Expand Messages
  • Stefan Stefanov
    Atif couldn t have said better. Stefan ... http://ide.li/ - ïîðòàë çà áúëãàðèòå ïî ñâåòà. Ñòàòèè, íîâèíè, ôîðóìè,
    Message 1 of 1 , Jul 24 1:39 PM
    • 0 Attachment
      Atif couldn't have said better.

      Stefan

      >-------- Оригинално писмо --------
      >От: "Atif Aziz" <atif.aziz@...>
      >Относно: RE : [json] __jsonclass__ hinting
      >До: <json@yahoogroups.com>
      >Изпратено на: Понеделник, 2006, Юли 24 21:00:31 EEST
      >----------------------------------
      >
      >What do you think of the the ideas presented in message #473:
      >http://groups.yahoo.com/group/json/message/473
      >
      >There's even an example in there about how to present the structure of a Person type. Keep in mind that the solution I presented is designed to solve the first level of problem, which is how to communicate the structure of your data out-of-band and at design-time. What hinting solves is the problem of polymorphism, a bit how XML deals with it through xsi:type in the instance document. In most cases, however, you want to know the structure at design-time as opposed to run-time (if you can help it). The run-time hinting is only interesting where the producer says I am going to give you an array of objects, but you'll have to go digging into each to determine what their actual type is. Even then, the discovered type is not about how you map it to language constructs, but rather how you can treat the data. Consequently, I fear that the problem of run-time hinting is destined (or doomed depending on how you see it) to be solved by your framework's mapping subsystem rather than b
      eing standardized on the wire. Here are the two main reasons I can think of why:
      >
      >*
      > Security. It may not be wise to blindly accept the type that the producer might want you to think a particular JSON data is.
      >
      >*
      > Decoupling. The producer or consumer may see the logical to physical type mapping different on each end of the wire. For example, the producer might use a single person class but an enum field to distinguish the actual types. The consumer, on the other hand, may wish to use discrete classes.
      >
      >The problem I see with type-hinting at run-time is that it's not just limited to reserving a property name. It also entails describing how to use that facility and this is a difficult exercise that produces limiting results. At best, it helps those small cases where folks on both ends don't wish to concern themselves with the wire format and where deployment timelines can be tightly linked. It's also not a new problem because ORM tools face the same issue with SQL result sets. The problem there is solved through the mapping language of the framework rather than changing the table schema (e.g., renaming the column to an commonly accepted name of, say, "__type") or layering additional views.
      >
      >- Atif
      >
      >
      >________________________________
      >
      >De: json@yahoogroups.com de la part de meyer_jon
      >Date: lun. 7/24/2006 5:03
      >À: json@yahoogroups.com
      >Objet : [json] __jsonclass__ hinting
      >
      >
      >
      >(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:
      >
      >{"__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:
      >
      >{
      >"__jsonclass__":["Person"],
      >"firstName": "Joe",
      >"lastName": "Smith",
      >"age": 23,
      >}
      >
      >There's an extra array per object during processing, but it conforms
      >to the spec.
      >
      >Comments?
      >
      >Jon
      >
      >
      >
      >[Non-text portions of this message have been removed]
      >
      >
      >
      >
      >Yahoo! Groups Links
      >
      >
      >
      >
      >
      >
      >
      >

      -----------------------------------------------------------------
      http://ide.li/ - портал за българите по света. Статии, новини, форуми, снимки, информация.
    Your message has been successfully submitted and would be delivered to recipients shortly.