jnape
commented
7 years ago Hi Roxxik -
First, your comments are certainly relevant to this library, so thanks for taking the time to write them.
There are a few points in your comments, so I'll address each in turn.
[...] but while looking through the readme in the chapter about lenses, something struck me: [...] this is obviously not a lawful lens [...]
Correct, and there's no getting around that statement.
[...] If this was done for convenience reasons [...]
A bit reductionist, but your instincts are correct. Originally b was also Optional<String>, but it occurred to me that if the README was a sales pitch for the utility purpose of lenses, and my audience was a community that likely had little to no experiences with them, the current examples are potentially less scary. I suspect this is a rather unsatisfying answer for you. Me, too.
[...] I'd suggest making the lenses lawful and adding prisms (doing it right) [...]
I take this point to heart, and would like to offer an approximation of both Traversable and Applicative in Java, at which point Prism and Traversal should be nearly trivial. I've spiked out what I think is a reasonable Java approximation of both on a stash somewhere, so hopefully these will arrive in the near future.
[...] or explicitly say that the lenses are [unlawful] [...]
I will consider how best to annotate the documentation, pursuant to your concerns.
[I] think only providing java with lenses won't go a long way, [...] Keeping it immutable is a bonus from lenses. And polymorphic updates are too. But having Prisms and Traversals pushes this even further [...]
I get it, and agreed (mostly).
I haven't considered the verboseness of this in Java which might hinder the overall goal
And especially more contrived use cases where you want indexed optics can be difficult to get right in java, but might be worth it
I am Jack's eternal struggle.
In the meantime, let's call this particular Issue "Add disclaimers in the documentation for unlawful lenses", agreed?
Roxxik
just dropping some comment, might not even be relevant for this lib:
I just found this and i really like the idea to make stuff visible in the types and having some bits of experience in Java and Haskell, i might even use this in the future
but while looking through the readme in the chapter about lenses, something struck me:
lenses have to fullfill 3 laws, and if you do so you can vary the 4 type parameters of a lens freely. they are (https://hackage.haskell.org/package/lens-4.15.1/docs/Control-Lens-Lens.html)
1) You get back what you put in:
2) Putting back what you got doesn't change anything:
3) Setting twice is the same as setting once:
coming back to the first example:
would be something like: (where [] is List)
this is obviously not a lawfull lens. getting and then setting won't work, bc of the types involved.
some other examples are violating the laws, too.
If this was done for convenience reasons, I'd suggest making the lenses lawful and adding prisms (doing it right) or explicitly say that the lenses are broken. This is common in Haskell, some lenses can be unlawful under certain circumstances, but it is documented.
Just some random thoughts from me: i think only providing java with lenses won't go a long way, because accessors already compose (foo.bar.baz -> no need for view(bar.compose(baz),foo) ). Keeping it immutable is a bonus from lenses. And polymorphic updates are too. But having Prisms and Traversals pushes this even further, eleminating the need for Iterators and explicit Optional handling.
I haven't considered the verboseness of this in Java which might hinder the overall goal.
And especially more contrived use cases where you want indexed optics can be difficult to get right in java, but might be worth it
EDIT: Grammar