15 comments

[ 3.1 ms ] story [ 54.8 ms ] thread
Cool. Whats is the use-case?

Edit - I hate to bitch about downvotes (as per http://ycombinator.com/newsguidelines.html), but can the downvoters to my comments in the thread, please respond, why the downvotes? Are my comments Off-Topic, rude or not adding to the discussion? Since, I am genuinely curious about all my queries.

There are a couple of places in .net where json can be deserialized into a c# class you provide, for example posting json to an asp.net mvc controller action. I find it is a massive pain to go through and create the classes manually.
Just to clarify, you mean that a json object can be deserialized into an object of the c# class, right? or just the class definition (as done by the site)?

If latter, how do you use the class definition generated dynamically? (without the values, that is)

Yeah an object of the class. Sorry about that.
Thats OK. I have had the case of convert Json to Language Class objects myself before.
This generate strong types from example JSON messages, and there are handy methods in C# that let you take a JSON string and parse it as a given class. This way, other devs know what fields to expect in the JSON message and saves them time on digging through the raw JSON.
I understand the benefits of object oriented approach, vs the free formed JSON.

Is it possible to create class dynamically in C#, or is it supposed to be one time effort (and the tool does it automatically it, as opposed to doing it manually)?

It is possible to create class dynamically in C#. Although I don't know whether this library is doing it.
Typically with something like this it will be a one time effort because the code produced is what enables the development time tools like intellisense. .Net does have run time code generation options but unfortunately we don't have support in the tool chain to tie them back to these sorts of tools.
Dynamic support is present in .NET/C# as of version 4.0. Consuming JSON in applications written or currently running on prior versions leaves one with little choice than writing static types to deserialize to.
Cute. Minor point: it doesn't check for invalid field/classnames, e.g.

    {"{ [ string" : ""}
Thank you, 6ren. The service will be extended and the first feature on my list is displaying erroneous submissions such as this.
(comment deleted)
Thinking on this further, you're really doing two things: extracting a schema from an instance; and converting it to C# classes.

1) extracting the schema from an instance: in a JSON instance, a list will have some number of elements; but in a schema, you just have the concept of a list, and what it may possibly contain. Because JSON doesn't explicitly facilitate choice or references, they can't be automatically extracted (in the rare cases where someone implements this, they do it in their own non-standard way on top of JSON). JSON also doesn't represent the idea of productions - fair enough, since productions are a schema/grammar-level concept, which simply don't appear in an instance. (In general, there are many different ways of dividing up a grammar into production that yield identical languages ie. the set of possible instances.)

2) representing this schema in C# classes. This is conceptually straightforward, once you've got the schema.

In practice, these two steps almost disappear, even conceptually, because (with the exception of lists), you are just making classes that have the equivalent contents to each object in the JSON instance.

i.e. you can see it as an isomorphism:

  mapping from JSON "objects" (within {}) to C# classes; and
  recursively within that, from
    JSON "fields" to C# fields and
    JSON values (int, boolean, string etc) to C# primitive types.
(BTW: The mapping of objects to classes is instance-to-schema.)

Lists are an exception to this isomorphism:

  mapping a JSON list (within []) to a C# list/array,
    the _elements_ of a JSON list are not _all_ mapped -
    only one is mapped (eg. a JSON "object" is mapped to a class)