Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arguments against JSON-driven development

okigiveup.net

Post reply on HN
Print view View original

21–30 of 306 posts

Re: Arguments against JSON-driven development

#21

Post by tantalor »

Cthulhu_ wrote: post #8

I disagree with the anemic object argument. 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. A large portion of back-end services are CRUD and data wrangling operations anyway - as in, convert data format A to data format B (which I guess could be a constructor or factory method if you're comfortable with having the conversion logic in a data cla…

Especially true if your business objects are generated code, e.g., protocol buffers.

Combining business logic with business objects is a mistake. That's a textbook example of tight coupling.

Re: Arguments against JSON-driven development

#22

Post by aeruder »

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

An article about the "attrs" library was posted here a couple weeks ago. Really highlighted the tedium of Python objects while offering a neat solution.

https://glyph.twistedmatrix.com/2016/08/attrs.html

Regarding protobuf, I'm a bit disappointed with the direction of version 3. Fields can no longer be marked as required - everything is optional; i.e. almost every protobuf needs to be wrapped with some sort of validator to ensure that necessary fields are present. I understand the arguments, but I did enjoy letting protobuf do the bulk of the work making sure fields were present.

Re: Arguments against JSON-driven development

#23

Post by sevensor »

tantalor wrote: post #15
lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

Named tuples assign meaning to each position in a tuple and allow for more readable, self-documenting code. They can be used wherever regular tuples are used, and they add the ability to access fields by name instead of position index. https://docs.python.org/2/library/collections.html#collectio...

Named tuples are pretty great! I used to think their immutability was a drawback, but I'm starting to come around to the opposite point of view.

Re: Arguments against JSON-driven development

#26

Post by catnaroek »

lmm wrote: post #11

The main reason this happens in Python is that creating actual datatypes is incredibly clunky (by Python standards) because of the tedious "def __init__(self, x): self.x = x". The solution here is to have a very lightweight syntax for more specific types, e.g. Scala's "case class". I'd also argue for using thrift, protobuf or even WS-* to put a little more strong typing into what goes over the network. Such schemata…

> The main reason this happens in Python is that creating actual datatypes is incredibly clunky

It's not clunky, it's outright impossible. Datatypes are inhabited by compound values (data constructors applied to arguments), but Python simply doesn't have compound values. All it has is object identities, which are primitive and indecomposable values no matter how compound the object is.

Sadly, the same is true in Scala.

Re: Arguments against JSON-driven development

#27

Post by sevensor »

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.

As tantalor reminds us in a sibling comment, the named tuple works nicely in this role.

Re: Arguments against JSON-driven development

#29

Post by catnaroek »

sevensor wrote: post #27
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.

As tantalor reminds us in a sibling comment, the named tuple works nicely in this role.

All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.

Re: Arguments against JSON-driven development

#30

Post by rattray »

Cthulhu_ wrote: post #7
wtbob wrote: post #5

> The fundamental advice on Unicode is decode and encode on system boundaries. That is, you should never be working on non-unicode strings within your business logic. The same should apply to JSON. Decode it into business logic objects on entry into system, rejecting invalid data. Instead of relying on key errors and membership lookups, leave the orthogonal business of type validity to object instantiation. This righ…

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 think this might be where tools like Flow or TypeScript can become useful, since you can have typed javascript objects.

On the other hand, the fact that there's no runtime typecheck renders static analysis somewhat impotent when it comes to the result of a network call.

Post reply on HN