#1408 withUnaryOperator style flag/naming template #1409
Conversation
|
walk-in reviews are welcome |
| ImmutableWithUnaryOperator t = m.mapA(a -> a + 1) | ||
| .mapB(b -> "[" + b + "]") | ||
| .mapL(String::toUpperCase) | ||
| .mapO(o -> o.replace('*', '_')); |
There was a problem hiding this comment.
does it make sense to have flatMap on optionals ?
There was a problem hiding this comment.
Maybe, idk. Because how this feature is activated (by a naming template), I see that flatmap will require separate style flag to enable, Style.withFlatmap for example.
Also it would be fair for collections to also have flatmap, but it will probably need 2 overloads, like Function<? super T, ? extends Iterable<? extends T>> and Function<? super T, Stream<? extends T>>.
BTW (or "did you know?") I've just learned couple of days ago that you can return null in the map function (JDK Optional)
assert Optional.of("X").map(x -> null).isEmpty(); // no NPEI think if there would be any demand for flatMap, which I see as a separate flag, I can implement flatMap for optional / collections. Otherwise, Encodings should be used to customize any other specific container or collection.
I've already planned to add smth simple for map, there were at least couple of use cases where this is useful for us. Flatmap is more exotic in that sense, that while it's logical to have, we have never needed it on the surface of immutable object.
|
Eugene, a while ago you mentioned a more generic and functional approach to modifying Immutables: Lenses/Prisms/Traversables (see comment). Is it something you're still considering ? |
Yes, that still on the radar somewhere. Here, I've tried to address only simple a tool for mapping. Right now I'm not sure that this particular usecase would be simpler if lenses are used, it would be more scary looking for sure. But that is actually the API design exercise. I've got to designing something similar while working on Typescript codegen for the data models, the result was pretty interesting and not exactly what I thought it would be, some food for thought. So, the question is if there is demand for this? The other thing on the radar is the idea of Immutables 3 with more manageable models and many plugin points, this is for some newer LTS (JDK 11+ or even JDK 17+). And any complex new functionality could be implemented on top of that. |
|
thanks for the comments! I think if there's strong demand for related functionality we should discuss it further. Will merge this one. I wanted it to be a simple "no ambition" feature to update things with the function and not be on par with functor-ish (or monadic) |
Implementation of #1408 using naming template as enabling style flag