Closed Kauko closed 8 years ago
Thank you very much for the detailed explanation.
The issue 1, can be easy solved, so I'll fix it today.
The issue 2 and 3 they are not easy to solve, because a lenses are just functions, in the same way as transducers are (they uses the same technique and they are composable in the same way). So there are no way to identify if a lense that receives the l/focus-atom
is read only or not, because is just a function. This is because the returned atom is ISwap and IReset but throws an exception.
I think that trying to implement that checks will not have much value because the lenses are designed to be a generic approach for getters and setters and if some setter is not implemented, just and exception will be raised.
Maybe I'll consider adding a third argument to focus-atom
for explicitly return an atom that is read only independently of the received lense.
That would make sense. I'd say the first issue is a true bug, and I'm happy to hear it's easy to fix.
The second and third issue is not as critical, because errors resulting from these flaws can be considered to be an user error; if I create a read-only lens, and then give it to something that expects it to be writable, that would absolutely be my fault, right?
However, if I had a way to give the lens a property that explicitly says it's read-only, then other parts of my program could rely on the ISwap and IReset checks to see whether the atom they receive is writable or not. So I like your idea of having the option to specify that the lens is read-only :)
Nice, I'll try to do it today and rewrite some part of the doc for make it more easy for new comers ;)
Released 1.1.0 with fixes for this issue.
With lentes, two kinds of lenses can be created: two-way, writable lenses, and one-way, read-only lenses.
The bug is, bar does not satisfy
IAtom
:There is another problem related to the read-only lenses.
So, three problems really: