I have started working with VAVR for part of a project. So far, I like how they have approached collections (this library has basically rewritten/released a separate Collections API for Java!) and associated mutability; any mutation made to a collection returns a new collection -- it is not possible to modify an existing collection. The documentation for the library even goes so far as to call void return type a code smell because it implies that a method has side effects.
The push for immutability is a somewhat recent concept in programming, but VAVR is strongly on side of pushing for more immutability. So far, I tend to like where this is going; if I let you borrow/use an object in real life, I expect you to give me that object back in the same state I left it or to tell me that you've changed it somehow.
VAVR also takes a whole new approach to java streams (again, a whole separate API...) and introduces TupleX and FunctionX to support this approach. I'm not sure I like the TupleX concept. I understand that it is nice to have something to encapsulate some objects without having to define a whole new class/type for doing so. This inherently means less code, and most people like less code. Still, a part of me recoils because the whole point of OO is to provide encapsulation of related data/concepts. For me, following the logic of Tuple2, Tuple3, etc... means that I could have just written my whole code base with arrays and/or maps... definition, context, and clarity are provided by custom classes, and we lose these things with the spread of generic Tuples*.
*Tuple2, Tuple3, etc...are classes defined in VAVR. The concept of a tuple is not what I am discussing here. Tuple != tuple
Post a Comment