Arguments against JSON-driven development

Post by catnaroek » Thu, Aug 25, 2016, 2:40 PM UTC

qwertyuiop924 wrote: post #53

catnaroek wrote: post #17

> If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. In that case, you want values rather than objects. Alas, Python doesn't have compound values.

Please stop it. Every single time anything so much as slightly related comes up, you talk about compound object. Incessantly. And then you act superior when nobody knows what you mean, or cares about compound values. They're not really relevant to this discussion anyways, as storing data as desribed in GPP is perfectly reasonable. The worst part is, your definition of "value" and "object" in this context is so far ou…

Post by xyzzy4 » Thu, Aug 25, 2016, 2:42 PM UTC

K0nserv wrote: post #43

I agree with this and I've raised it several times in Objective-C codebases that can some times end up littered with NSDictionary:s everywhere taking no advantage of the Objective-C type mechanics. I don't think it's necessarily as bad in python or javascript. This is because these languages are dynamically typed and that diminishes the benefits of deserializing json to a native model. It's still valuable because you…

Post by qwertyuiop924 » Thu, Aug 25, 2016, 2:44 PM UTC

catnaroek wrote: post #59

qwertyuiop924 wrote: post #54

Earlier quoted context omitted.

...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.

It's useful when writing Prolog programs too.

Post by curveship » Thu, Aug 25, 2016, 2:45 PM UTC

adrianratnapala wrote: post #31

Cthulhu_ wrote: post #7

Earlier quoted context omitted.

When using parsers like e.g. Jackson or Gson for Java, this process is completely transparent and does not require any active thought from the developer - well, maybe if there's very specific formats that don't map 1:1 with the class that should be instantiated or generated from the json object. It's a bit more tricky in JS, both client-side and node. You can't work with the json string there, but after that you work…

I've never had good experiences with automated serialisation -- even though it sounds like other people do it with success. What's the secret? To give you a flavour of the kind of poblem: In C# (or rather .net) json.net reads JSON and calls setters from the target class. That means the setters have to be public, and you don't know what order they will be called in, and you have no real signal about when it is all don…

Post by [deleted] » Thu, Aug 25, 2016, 2:45 PM UTC

tscs37 wrote: post #28

JSON is best when it's solely used for serialization (or config files). Using it deep into the project makes no sense, the first step in handling JSON should always be to code it into native data structures.