Actually, Ed Kmett's (more recent) lenses are based on Twan van Laarhoven (twanvl) lenses. These are a major improvement over the original data-lens package that Ed, Russell and I were working toward.

The problem with twanvl lenses is that you need higher-kinds, right off the bat. Moreso, higher-kinds are exploited to represent the combination of all the different types of "optics." For example, a Functor constraint on one part of the optic denotes a lens, while a Profunctor constraint on another part denotes an isomorphism.

Traditionally, Functional Java has worked around this type system limitation (of Java) by simply repeating the code (yes, copy/pasting), since it has been argued that this is simply the next best thing in light of these limitations.

The question then is, can we apply this workaround to exploit the benefits of twanvl for Java? Just to clarify, the benefits of twanvl over the old "store comonad coalgebra" represenation (that is being proposed here) is absolutely enormous. Achieving this benefit would, of course, require lots of copy/pasting because of no higher kinds.

However, my gut feeling is that it is simply worth it. Implement twanvl lenses and incur the laborious penalty of copy/pasting where higher-kinds would otherwise alleviate it.

Yes, you're right, the proposed lenses are using a simple representation, a first start if you will. Also, there are other techniques beside higher-kinds, that are painful or impossible to use in Java but would be beneficial for lenses (such as templates/macros or actual typeclasses). However, I haven't yet studied the twanvl representation, so I've got no idea what implementing it in Java would mean, but I'm eager to learn from you.

@tonymorris I am not familiar with twanvl lenses, but is this a useful addition given Java's many limitations? I would imagine a twanvl lens representation would be a lot of extra work if it needed kinds immediately.

If we changed to twanvl lenses later, how would clients of a lens be affected?

May be the avatar of higher order types as implemented in https://code.google.com/p/highj/ could be a solution? But the verbose generics are a bit repulsive...

To get in the direction of higher order types I personally take a naive approach based on generics: https://gist.github.com/danieldietrich/6320d0d617ededbe05f7

I'm using it here for example: http://javaslang.com/javadoc/javaslang/monad/Option.html#flatMap-java.util.function.Function-

@danieldietrich you solution is technically very similar to the one used in highj. Except highj has better separation of concerns, ie List is not required to extends all the "pseudo type-classes" interfaces (foldables and the like). This allows creation of custom "type-classes" in client code.

@jbgi thank you for the feedback. I will take a look at highj!

I am going to close this PR, since this is addressed by @jbgi in #130 #131 and #132.