5 ms·

Justin Fagnani's response hits it head on. It makes no sense to deserialize schema-less JSON into objects. How is the compiler to know what classes you want i

Justin Fagnani's response hits it head on. It makes no sense to deserialize schema-less JSON into objects. How is the compiler to know what classes you want it to use? Even if you just want classes with no methods, the deserializer still needs to know what fields you expect. (Otherwise you have no guarantee what fields the object you're returned has, which is pretty useless!) Even more, what if you really want a JSON object to be deserialized as a key-value map, not an object? (Those support different functionality!) The compiler has no way of knowing this. Either you need to provide a schema, in which case it's easy to make a library to deserialize objects, or you're asking for something ill-defined.

d2p 12y ago
The class you're deserialising into is the Schema; exactly like C# manages to do it: var myPerson = deserialise<Person>(json); If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings!
- bad_user 12y ago
  One needs a way to override the deserialization though, as often the correspondence between that JSON map and the fields on Person is not exactly one to one - starting with something as simple as having camelCase in your Dart code and underscores in your JSON. Of course, it's not that hard to build such a library and it's fairly useful too.
  - d2p 12y ago
    This is invented complexity; there is no need to support this in order to satisfy the majority of requirements. Just because requirements can be made complicated doesn't mean there should be no support for something simple. The built-in .NET JSON serialise is very limited; and there are third party libraries (even used by MS themselves for ASP.NET) to address that.
    - bad_user 12y ago
      In my experience, in most cases I've encountered, the serialization/deserialization schema does need a few simple tweaks, mostly because JSON is a format used for interoperability (and you can't necessarily force the same conventions everywhere) and for APIs that change over time. And it's useful to be able to make minor tweaks to those conventions - otherwise you've got to chose between something super easy (based on reflection) or something that interprets a map and that ends up looking like vomit copy pasted from the Internet. I'm against super complex things, but things going into a standard library should be general enough for 80% of the use-cases in the wild (and no, I don't agree with you here), otherwise it's very hard to make changes in the standard library later, therefore instead of pushing for something half-baked, I would rather wait for third-parties to build such a library. Scala for example has a shitty JSON parser in the standard library that nowadays nobody uses because it is limited and because third-party libraries are better. I suspect, from what you're telling me, that C#'s standard parser is in the same league.
- jenscow 12y ago
  Why not create yourself a code generator, which analyses the class and generates code to perform the manual map<->object transfer?
  - d2p 12y ago
    Does this not sound like a rather complicated thing for the individual developers to do when 99% of Dart web apps will need to do this?
    - jenscow 12y ago
      Sure. But "99%" of developers just need serialisation, which is supported. You (and myself) want more than that.
      - d2p 12y ago
        Depends on your definition of "supported"? JSON uses maps (throwing away one of the big advantages of Dart) and the Serialisation package appears to rely on hard-coded rules or use mirrors (which are slow and apparently not a good thing to use in production dart2js code).
- rst 12y ago
  This may be easier in C# than in Dart because in C#, you have type declarations for all the members. In Dart, type declarations are optional. (And, IIRC, not supposed to change the behavior of the program, except for type-checks performed while running in "development" mode; even these are disabled in "production".)
  - deleted 12y ago
    [deleted]
- rmrfrmrf 12y ago
  > If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings! Why are you worried about type-safety? JSON itself only supports object, array, string, number, true/false, and null, so type safety isn't even an issue because invalid JSON will fail to parse. If you're talking about taking a string and regexing it into an address or whatever, then yeah: you should be writing that code yourself.
  - d2p 12y ago
    > Why are you worried about type-safety? Because that's one of the huge selling points of Dart?!
    - rmrfrmrf 12y ago
      I would invite you to read the rest of my comment.
      - d2p 12y ago
        I did; but it makes no sense. That's like saying "Why does Dart even both having classes"?. If you're writing a client application, you probably have data structures. Some of those data structures you need to send to the server (or receive). When you write code that interacts with those structures, you want code-completion; static analysis, etc.; that's kinda the point of Dart's typing!
- spankalee 12y ago
  It's possible to write this deserialize() function in Dart, but its simplicity requires many trade offs for anything other than toy uses, which is why it's not a missing part of the core platform. Having to choose your serialization strategy is not a bad thing. At the very least, Dart's JSON support is very similar to JavaScript already, and there are several packages that do serialization in different ways.
JoeAltmaier 12y ago
Ok so its ill-defined. It would be fine to do SOMETHING with it. E.g. I could interrogate the object to see what fields it did have, and make some conclusions. Useful depending on the app space. I could display the data for instance, maybe edit it.
- _delirium 12y ago
  It does do something: > in Dart ... Decoding JSON will get you Maps and Lists
deleted 12y ago
[deleted]
- rmrfrmrf 12y ago
  I think the point is that Dart can do that, but he wants to eliminate the step where you perform the cast and just have Dart automagically create meaningful classes from a given pile of JSON data. I think the performance penalty of this type dancing is obvious: deserialized JSON in JavaScript is already in its purest form, so going and copying bits and pieces of that data into new objects and then performing checks/manipulations on those pieces of data is going to take up a ton of excess memory and bazillions of wasted CPU cycles.
  - spankalee 12y ago
    Deserialized JSON in JavaScript is not necessarily in its most useful form: the objects produced have no useful prototype. Dart already has the equivalent to that with its built-in JSON codec - it deals in Maps and Lists. What the OP is asking for is for deserialization to produce instances of different classes. No matter that it's not possible to map generic JSON structures to classes and objects for anything other than trivial cases (polymorphism, interfaces, heterogenous collections and non-tree structures won't work), JavaScript doesn't produce objects with interesting prototype chains when deserializing JSON, so you'd still have to copy bit around if that's what you want.
nly 12y ago
> Justin Fagnani's response hits it head on. It makes no sense to deserialize schema-less JSON into objects. What you should typically do in static languages without reflection (C++ etc) is specify a mapping between the implicit JSON schema and your existing class definitions using a set of traits. Boost.Fusion for C++, for example, is one way to map an object to an arbitrary sequence you can utilise for serialization. Code generation approaches, like out of the box generation from 'Protocol Buffers', is ugly and limited anyway, since you're then forced wrap or abstract away the generated code, or put up with its style and limitations. If your JSON schema changes in the future, for example, you will have to change your code all over the place rather than just the serialize/deserialize routines.

d2p 12y ago

The class you're deserialising into is the Schema; exactly like C# manages to do it: var myPerson = deserialise<Person>(json); If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings!

bad_user 12y ago
One needs a way to override the deserialization though, as often the correspondence between that JSON map and the fields on Person is not exactly one to one - starting with something as simple as having camelCase in your Dart code and underscores in your JSON. Of course, it's not that hard to build such a library and it's fairly useful too.
- d2p 12y ago
  This is invented complexity; there is no need to support this in order to satisfy the majority of requirements. Just because requirements can be made complicated doesn't mean there should be no support for something simple. The built-in .NET JSON serialise is very limited; and there are third party libraries (even used by MS themselves for ASP.NET) to address that.
  - bad_user 12y ago
    In my experience, in most cases I've encountered, the serialization/deserialization schema does need a few simple tweaks, mostly because JSON is a format used for interoperability (and you can't necessarily force the same conventions everywhere) and for APIs that change over time. And it's useful to be able to make minor tweaks to those conventions - otherwise you've got to chose between something super easy (based on reflection) or something that interprets a map and that ends up looking like vomit copy pasted from the Internet. I'm against super complex things, but things going into a standard library should be general enough for 80% of the use-cases in the wild (and no, I don't agree with you here), otherwise it's very hard to make changes in the standard library later, therefore instead of pushing for something half-baked, I would rather wait for third-parties to build such a library. Scala for example has a shitty JSON parser in the standard library that nowadays nobody uses because it is limited and because third-party libraries are better. I suspect, from what you're telling me, that C#'s standard parser is in the same league.
jenscow 12y ago
Why not create yourself a code generator, which analyses the class and generates code to perform the manual map<->object transfer?
- d2p 12y ago
  Does this not sound like a rather complicated thing for the individual developers to do when 99% of Dart web apps will need to do this?
  - jenscow 12y ago
    Sure. But "99%" of developers just need serialisation, which is supported. You (and myself) want more than that.
    - d2p 12y ago
      Depends on your definition of "supported"? JSON uses maps (throwing away one of the big advantages of Dart) and the Serialisation package appears to rely on hard-coded rules or use mirrors (which are slow and apparently not a good thing to use in production dart2js code).
rst 12y ago
This may be easier in C# than in Dart because in C#, you have type declarations for all the members. In Dart, type declarations are optional. (And, IIRC, not supposed to change the behavior of the program, except for type-checks performed while running in "development" mode; even these are disabled in "production".)
- deleted 12y ago
  [deleted]
rmrfrmrf 12y ago
> If you want a map, that's already supported; but you'll lose all the "type-safety" that Dart brings! Why are you worried about type-safety? JSON itself only supports object, array, string, number, true/false, and null, so type safety isn't even an issue because invalid JSON will fail to parse. If you're talking about taking a string and regexing it into an address or whatever, then yeah: you should be writing that code yourself.
- d2p 12y ago
  > Why are you worried about type-safety? Because that's one of the huge selling points of Dart?!
  - rmrfrmrf 12y ago
    I would invite you to read the rest of my comment.
    - d2p 12y ago
      I did; but it makes no sense. That's like saying "Why does Dart even both having classes"?. If you're writing a client application, you probably have data structures. Some of those data structures you need to send to the server (or receive). When you write code that interacts with those structures, you want code-completion; static analysis, etc.; that's kinda the point of Dart's typing!
spankalee 12y ago
It's possible to write this deserialize() function in Dart, but its simplicity requires many trade offs for anything other than toy uses, which is why it's not a missing part of the core platform. Having to choose your serialization strategy is not a bad thing. At the very least, Dart's JSON support is very similar to JavaScript already, and there are several packages that do serialization in different ways.

JoeAltmaier 12y ago

Ok so its ill-defined. It would be fine to do SOMETHING with it. E.g. I could interrogate the object to see what fields it did have, and make some conclusions. Useful depending on the app space. I could display the data for instance, maybe edit it.

_delirium 12y ago
It does do something: > in Dart ... Decoding JSON will get you Maps and Lists

deleted 12y ago

[deleted]

rmrfrmrf 12y ago
I think the point is that Dart can do that, but he wants to eliminate the step where you perform the cast and just have Dart automagically create meaningful classes from a given pile of JSON data. I think the performance penalty of this type dancing is obvious: deserialized JSON in JavaScript is already in its purest form, so going and copying bits and pieces of that data into new objects and then performing checks/manipulations on those pieces of data is going to take up a ton of excess memory and bazillions of wasted CPU cycles.
- spankalee 12y ago
  Deserialized JSON in JavaScript is not necessarily in its most useful form: the objects produced have no useful prototype. Dart already has the equivalent to that with its built-in JSON codec - it deals in Maps and Lists. What the OP is asking for is for deserialization to produce instances of different classes. No matter that it's not possible to map generic JSON structures to classes and objects for anything other than trivial cases (polymorphism, interfaces, heterogenous collections and non-tree structures won't work), JavaScript doesn't produce objects with interesting prototype chains when deserializing JSON, so you'd still have to copy bit around if that's what you want.

nly 12y ago

> Justin Fagnani's response hits it head on. It makes no sense to deserialize schema-less JSON into objects. What you should typically do in static languages without reflection (C++ etc) is specify a mapping between the implicit JSON schema and your existing class definitions using a set of traits. Boost.Fusion for C++, for example, is one way to map an object to an arbitrary sequence you can utilise for serialization. Code generation approaches, like out of the box generation from 'Protocol Buffers', is ugly and limited anyway, since you're then forced wrap or abstract away the generated code, or put up with its style and limitations. If your JSON schema changes in the future, for example, you will have to change your code all over the place rather than just the serialize/deserialize routines.