Making Lenses Practical in Java

The problem this is trying to resolve is creating copies of a complex immutable class with some deep fields changed. I do have to wonder for a case like this if using a mutable object with a deep copy function wouldn't be a better solution, rather than adding extra magic to do it more easily as possible...

Edit: The code in the article would become something like

  pendingOrders.map(order -> { 
    copy = order.DeepCopy();   
    copy.getApproval()
        .getConfirmation()
        .setUpdatedOn(LocalDateTime.now())); 
    return copy;
    } 
  )

(of course, we could also get rid of the getters and setters and replace them with direct field access, if we take the data class concept seriously)

Re: Making Lenses Practical in Java

#6

Post by Garlef » Sun, Jan 15, 2023, 8:51 PM UTC

javaunsafe2019 wrote: post #3

I just use Kotlin. Never looked back.

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

Re: Making Lenses Practical in Java

#7

Post by _old_dude_ » Sun, Jan 15, 2023, 8:58 PM UTC

I believe this is a case where a named tuple of functions, a record, is better than an interface.

    public record Lens(Function get, BiFunction with) {
      public  Lens compose(Lens inner) {
        return new Lens(
          inner.get.compose(get),
          (a, c) -> with.apply(a, inner.with.apply(get.apply(a), c)));
      }
    }

    Lens $updatedOn =
      new Lens(Confirmation::updateOn, Confirmation::updateOn);

Re: Making Lenses Practical in Java

#8

Post by ImprobableTruth » Sun, Jan 15, 2023, 9:09 PM UTC

tsimionescu wrote: post #5

The problem this is trying to resolve is creating copies of a complex immutable class with some deep fields changed. I do have to wonder for a case like this if using a mutable object with a deep copy function wouldn't be a better solution, rather than adding extra magic to do it more easily as possible... Edit: The code in the article would become something like pendingOrders.map(order -> { copy = order.DeepCopy();…

The issue is that this potentially copies a lot of unnecessary information. Also, if you depend on object identities (reference equality), deep copying will recreate objects even if they aren't supposed to change. Furthermore, if you want to chain two update functions, you'll deep copy parts of the object twice times.

Lenses are "smart" in the sense that they only copy what's necessary.

Re: Making Lenses Practical in Java

#9

Post by fedeb95 » Sun, Jan 15, 2023, 9:10 PM UTC

I don't agree on the fact that lombok has brought us out of the dark ages. We used to use it, but it has some drawbacks. One of them, it's an additional dependency. This, for a simple thing such as pojo, seems a bit overkill to me. The additional amount of time used to write some cose isn't worth the risk of additional bugs hidden in having one more dependency.

Re: Making Lenses Practical in Java

#10

Post by marginalia_nu » Sun, Jan 15, 2023, 9:35 PM UTC

fedeb95 wrote: post #9

I don't agree on the fact that lombok has brought us out of the dark ages. We used to use it, but it has some drawbacks. One of them, it's an additional dependency. This, for a simple thing such as pojo, seems a bit overkill to me. The additional amount of time used to write some cose isn't worth the risk of additional bugs hidden in having one more dependency.

Record classes arguably do a lot of the same thing without the drawbacks.