4 ms·

I just use Kotlin. Never looked back.

by javaunsafe2019 4y ago

Garlef 4y ago
Sure. But what does that have to do with lenses?
googlryas 4y ago
How do you update a deeply nested immutable type in kotlin?
- david_allison 4y ago
  https://arrow-kt.io/docs/optics/lens/ https://arrow-kt.io/docs/optics/lens/
- ackfoobar 4y ago
  Lenses work today. And I think the value class feature will be awesome. https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md#deep-mutations https://github.com/Kotlin/KEEP/blob/master/notes/value-class...
jeroenhd 4y ago
Kotlin alone won't implement these features for you. You'd end up with something like this: val order = loadOrder() val approved = order.copy( approval = order.approval.copy( confirmation = order.approval.confirmation.copy(updatedOn = Instant.now()), status = ApprovalStatus.Approved ) I think I prefer this explicit deep cloning over the automagically generated lenses in standard code, but I can see the appeal. The problem is that mutated copies of immultable objects with deeply nested properties that need to be updated just requiresa lot of code. On the other hand, if I were to design the application in Kotlin, I wouldn't use such a deeply nested object graph if I was going to constantly duplicate theses objects. I also think constantly creating and destroying immutable objects is a sign of immutability being used in the wrong place; I don't know why you wouldn't simply mutate state if the goal is to mutate the state. With Kotlin, but also Java, you could then very easily achieve these changes. Lenses are available as a package for both Java and Kotlin so the concept is hardly language specific. People find a use for them in both languages, even if I don't see the point, and that means just switching to a better language isn't the solution here.
- brabel 4y ago
  I like to call this "direct code". It does exactly what it looks like it does. Lenses do not, they introduce a whole abstraction around something as simple as get/set. For this reason, the Kotlin code above would be much preferred IMO.
  - jeroenhd 4y ago
    I agree, but the Kotlin code isn't that different from the Java code in the blog. The biggest difference is that Java lacks the necessary built-in support and relies on Lombok to provide the necessary copy helpers, but I can't think of a reason for a Java project not to use Lombok. I see Kotlin as better Java, but with the right compiler extensions (Lombok, Manifold) you can turn Java into a pretty modern language as well, if you're not writing legacy code in Java 8/9/11. The specific approach this article is about doesn't really put Kotlin at an advantage, nor does it place it at an advantage. You might as well write the Lens pattern in Python or Rust, the idea is still the same.
- javaunsafe2019 4y ago
  For the example provided I would encapsulate that logic in the object itself returning a confirmed copy as a return. And as someone else pointed out I also much prefer explicit code where you easily can understand what is going on…
  - jeroenhd 4y ago
    I agree that I'd approach this in the form of (`val completed = order.approveAs(currentUser, Instant.now())` or maybe `val completed = orderService.approve(currentUser, Instant.now())`) myself. That doesn't require any specific programming language either. I was just using the example in the blog. However, I don't see Kotlin as a language that sticks to explicit code where you can understand what is going on. Between extensions, companion objects, infix methods and other syntactic sugar, I would say Java is much better in terms of code explicitness.

I just use Kotlin. Never looked back.

Garlef 4y ago

Sure. But what does that have to do with lenses?

googlryas 4y ago

How do you update a deeply nested immutable type in kotlin?

david_allison 4y ago
https://arrow-kt.io/docs/optics/lens/ https://arrow-kt.io/docs/optics/lens/
ackfoobar 4y ago
Lenses work today. And I think the value class feature will be awesome. https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md#deep-mutations https://github.com/Kotlin/KEEP/blob/master/notes/value-class...

jeroenhd 4y ago

Kotlin alone won't implement these features for you. You'd end up with something like this: val order = loadOrder() val approved = order.copy( approval = order.approval.copy( confirmation = order.approval.confirmation.copy(updatedOn = Instant.now()), status = ApprovalStatus.Approved ) I think I prefer this explicit deep cloning over the automagically generated lenses in standard code, but I can see the appeal. The problem is that mutated copies of immultable objects with deeply nested properties that need to be updated just requiresa lot of code. On the other hand, if I were to design the application in Kotlin, I wouldn't use such a deeply nested object graph if I was going to constantly duplicate theses objects. I also think constantly creating and destroying immutable objects is a sign of immutability being used in the wrong place; I don't know why you wouldn't simply mutate state if the goal is to mutate the state. With Kotlin, but also Java, you could then very easily achieve these changes. Lenses are available as a package for both Java and Kotlin so the concept is hardly language specific. People find a use for them in both languages, even if I don't see the point, and that means just switching to a better language isn't the solution here.

brabel 4y ago
I like to call this "direct code". It does exactly what it looks like it does. Lenses do not, they introduce a whole abstraction around something as simple as get/set. For this reason, the Kotlin code above would be much preferred IMO.
- jeroenhd 4y ago
  I agree, but the Kotlin code isn't that different from the Java code in the blog. The biggest difference is that Java lacks the necessary built-in support and relies on Lombok to provide the necessary copy helpers, but I can't think of a reason for a Java project not to use Lombok. I see Kotlin as better Java, but with the right compiler extensions (Lombok, Manifold) you can turn Java into a pretty modern language as well, if you're not writing legacy code in Java 8/9/11. The specific approach this article is about doesn't really put Kotlin at an advantage, nor does it place it at an advantage. You might as well write the Lens pattern in Python or Rust, the idea is still the same.
javaunsafe2019 4y ago
For the example provided I would encapsulate that logic in the object itself returning a confirmed copy as a return. And as someone else pointed out I also much prefer explicit code where you easily can understand what is going on…
- jeroenhd 4y ago
  I agree that I'd approach this in the form of (`val completed = order.approveAs(currentUser, Instant.now())` or maybe `val completed = orderService.approve(currentUser, Instant.now())`) myself. That doesn't require any specific programming language either. I was just using the example in the blog. However, I don't see Kotlin as a language that sticks to explicit code where you can understand what is going on. Between extensions, companion objects, infix methods and other syntactic sugar, I would say Java is much better in terms of code explicitness.