4 ms·

We had a few places where we had some headscratchers. First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a d

We had a few places where we had some headscratchers. First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there. Closed classes by default can make some testing a little more difficult. We have continued using Spock rather than moving our tests to Kotlin, and there are a few places where we compromise our design until we can figure out a better way. (Yes. Dependency Injection and less coupling is the answer, alongside adding a level of abstraction in between third parties. The devil is in the details.) In general, we like it and are planning on expanding our use, but conversion has had its challenges.

emodendroket 9y ago
> First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there. Does it? I really prefer JSON.NET's approach, which involves declaring models that represent your JSON, over dynamic "hope it's there" approaches.
- Guthur 9y ago
  False equivalence. You can static check this until you ate blue in the face but you still 'hope its there'. You would specify the contract for runtime checking like any sane engineer
  - emodendroket 9y ago
    Yes, but I don't have to worry about something like unintentionally spelling it differently on different lines, and in the case where I'm controlling both ends it is truly taken care of for me.
eropple 9y ago
What trouble did you run into with JSON? I just make Jackson objects as data classes and I'm done with it. Mucking with ObjectNode/ArrayNode is a bit annoying but not too bad, especially when you can map and collect. Was gonna say what you did about testing, but you have it, so, yeah. ;)
- ebiester 9y ago
  Short answer is the presence or absence of a field can drive us to different paths in the code base. That can lead to code littered with !! and @JsonIgnoreProperties(ignoreUnknown=true), or multiple intermediary data classes, or similar solutions. For much of our problem space, an extra val or two and some well placed ifs get us out of it.
- deleted 9y ago
  [deleted]
ismail-s 9y ago
Regarding closed classes, the all-open plugin ( https://kotlinlang.org/docs/reference/compiler-plugins.html#all-open-compiler-plugin https://kotlinlang.org/docs/reference/compiler-plugins.html#... ) may be able to help somewhat, though you'll still need to add an annotation to your base classes.

emodendroket 9y ago

> First, it took a little time to get the hang of json manipulation. We got to a solution we liked, but a dynamically typed language like groovy has some advantages there. Does it? I really prefer JSON.NET's approach, which involves declaring models that represent your JSON, over dynamic "hope it's there" approaches.

Guthur 9y ago
False equivalence. You can static check this until you ate blue in the face but you still 'hope its there'. You would specify the contract for runtime checking like any sane engineer
- emodendroket 9y ago
  Yes, but I don't have to worry about something like unintentionally spelling it differently on different lines, and in the case where I'm controlling both ends it is truly taken care of for me.

eropple 9y ago

What trouble did you run into with JSON? I just make Jackson objects as data classes and I'm done with it. Mucking with ObjectNode/ArrayNode is a bit annoying but not too bad, especially when you can map and collect. Was gonna say what you did about testing, but you have it, so, yeah. ;)

ebiester 9y ago
Short answer is the presence or absence of a field can drive us to different paths in the code base. That can lead to code littered with !! and @JsonIgnoreProperties(ignoreUnknown=true), or multiple intermediary data classes, or similar solutions. For much of our problem space, an extra val or two and some well placed ifs get us out of it.
deleted 9y ago
[deleted]

ismail-s 9y ago

Regarding closed classes, the all-open plugin ( https://kotlinlang.org/docs/reference/compiler-plugins.html#all-open-compiler-plugin https://kotlinlang.org/docs/reference/compiler-plugins.html#... ) may be able to help somewhat, though you'll still need to add an annotation to your base classes.