Immutable data

[serras]

No description provided.

[gutiory]

LGTM!
Great job @serras!
I've just found a typo.

[nomisRev]

Couple of nits, and questions. Overall it looks really great 🙌

[nomisRev]

Not sure if matching is a term that is as well known in Kotlin as Haskell or Scala. Can we somehow specify it's related to when?

[nomisRev]

Nit: Should we start this document talking about nullable fields? Seems quite a big jump to go immediately to collections 🤔 And IMO we're missing a bit on how this works in the DSL. IIRC we're not generating Optional anymore and instead only Prism and using notNull in the DSL?

IIRC we disabled them from generating (?). I thought we were going to do the same thing for nullable as Option.

@optics data class Person(val email: String?, val optEmail: Option<String>) {
  companion object {
  /** Generated */
    val email: Lens<Person, String?> = TODO()
    val optEmail: Lens<Person, Option<String>> = TODO()
  }
}

val x: Optional<Person, String> = Person.email.notNull
val y: Optional<Person, String> = Person.optEmail.some

Just saw this is briefly mentioned at the bottom.

[serras]

This is mostly based on the fact that I perceived that people had trouble understanding how Optional works with nullable fields, because of the fact that they cannot change to something which is not null with lenses. I think that the same idea is better understood for collections (not being able to add or remove elements).

Furthermore, the change to generate Lens instead of Optional is due to Arrow 2.x, because it's a breaking change. This only adds a bit more noise to the fact that nullable fields are somehow in flux in Arrow.

In any case, I'm happy to bring back the nullable fields; there's definitely some help from doing it that way (for example, we can compare with ?. and so on).

[nomisRev]

This is mostly based on the fact that I perceived that people had trouble understanding how Optional works with nullable fields, because of the fact that they cannot change to something which is not null with lenses. I think that the same idea is better understood for collections (not being able to add or remove elements).

Makes sense, should we include a section on :::danger Nullable types. Or at least an example and comparing to the collection section at the beginning of the document?

Furthermore, the change to generate Lens instead of Optional is due to Arrow 2.x, because it's a breaking change. This only adds a bit more noise to the fact that nullable fields are somehow in flux in Arrow.

I'm not arguing against this change, I am very happy with the improvements made in Arrow 2.x. Just wondering if we should clarify how it works a bit more in this document.

[serras]

I'm not arguing against this change, I am very happy with the improvements made in Arrow 2.x. Just wondering if we should clarify how it works a bit more in this document.

No worries, I know that you're fully on board with the new changes. The problem when I was writing it was how to be clear enough about both behaviors, but not confuse the reader with too many small details.

[serras]

I've added a heading with an explanation of notNull

[nomisRev]

Should we mention here that Lens<Person, String?>, and ``Lens<Person, Option>` does have this capability?

[serras]

I've added an additional paragraph explaining this.

[franciscodr]

Great stuff, @serras!

[nomisRev]

Great addition, this was one of the StackOverflow questions some time ago 🙌

[nomisRev]

Looks great @serras 🙌 Awesome work 👏 👏