Skip to main content

VAVR

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
Labels:

Comments

Post a Comment

Popular posts from this blog

Spring Security - Authority vs Role

I have spent a lot of time recently trying to understand the difference between Authority and Role in Spring Security.  This is a brief review of what I found. When creating a UserDetailsService or overriding configure(AuthenticationManagerBuilder auth) in the security config class that extends WebSecurityConfigurerAdapter, I basically get complete control over what I populate inside of the UserDetails that is used/returned.  This is important because the UserDetails interface really only cares about how to return one thing: Collection<? extends GrantedAuthority> getAuthorities(); A GrantedAuthority just seems like a glorified String wrapper that names some thing.  The question is... what is that thing? This is where the subtle difference between Authority and Role comes into play. I think that Role is an older thought/construct that automatically gets plugged into Authority if we just create a user with a Role.  But completely forget about the code a...
Post a Comment
Read more

SQL, Booleans, JPA, and Hibernate

For a long time, SQL and Booleans have not gotten along.  Standards for SQL never really addressed the need for boolean data -- it was assumed that some other data type could easily just step in and address this need.  The result was a lot of different data models for boolean values.  Here are some examples. TRUE or FALSE T or F Y or N 1 or 0 <any value> vs NULL The internet shows the debate has gone on , even as SQL standards have changed .  Coming from a professional background with Oracle, I struggled with this across my teams because everyone had a different opinion, which led to a lot of time wasted due to debate. This said, I appreciate working with native queries in hibernate's JPA implementation against MySQL.  MySQL supports a BIT data type I recently discussed .  When we represent data in MySQL with BIT and restrict the length to just 1 (ie 1 bit), Hibernate JPA magically knows to query and return this data as a Boolean in the ...
Post a Comment
Read more

ANSI-92 SQL Syntax - aka "JOIN" me in software progress!

 I've run into several projects lately that don't use and/or refuse to use the JOIN keyword/syntax.  I've had conversations in these projects to help people understand that, but I wonder why this is not more common across SQL database projects.  This standard is not new, and it more easily defines the join section vs the WHERE/filter section, so it has good benefits.  So far, the only reason I have heard to not use it is "we just don't tend to do that here."  This makes me sad. I hope to continue evangelizing small changes like this in my projects, be it JOIN, use of functional programming, listening to IDE feedback (great static analysis checking... available before you ever even push!), etc.  There are so many small things that help make software easier for everyone, I think.
Post a Comment
Read more