• Optional<Comment> (unregistered)

    return comments.stream().findFirst(Comment::isFrist);

    I don't agree that a lambda is less readable than a Java method reference, actually. A lambda clearly shows you the parameters, a method reference requires you to be familiar with the method to understand it. Though in this case neither is hard to read.

  • Naomi (unregistered)

    That would be comments.stream().min(Comment::postDate), but if your data structure forces you to do an O(N) operation just to find the oldest, it's time to refactor. If comments is a List you would just do comments.isEmpty() ? Optional.empty() : Optional.of(comments.get(0)).

    And to nitpick the article, Collection#stream() returns a Stream. A StreamBuilder is a pseudo-collection that you can add values to before streaming it.

    (Interestingly enough, lambdas are sugar for method references, not the other way around - when you use a lambda, the compiler generates a method and takes a reference to it. You can see this most easily in a debugging session, or in a stack trace. The more you know!)

  • Hal (unregistered) in reply to Optional<Comment>

    I agree lambda vs method reference each have merits here. Honestly it comes down to an aesthetic choice IMHO. I would probably do whatever is most consistent with the existing code base.

  • podlesh (unregistered)

    The Optional deconstruct-construct command is basically just the good old "return booleanValue==true" for 21st century.

  • (nodebb)

    I get the feeling that this is the result of a method that originally returned a CachedSession rather than an Optional of a CachedSession. In my mind the way this played out was:

    1. return theSession.get()
    2. "oh hey the linter says I need to check isPresent() before calling get()"
    3. if theSession.isPresent() return theSession.get() else return null
    4. during code review the reviewer says "hey let's make just return an optional so that the caller knows it might be null"
    5. "oh it works now how do I make this return an optional without breaking my code"
    6. we get today's WTF
  • Jezor (unregistered)

    A lambda clearly shows you the parameters, a method reference requires you to be familiar with the method to understand it.

    Parameters are just an extra name you need to keep track of. If the method is named properly, you should be able to understand it as is.

  • ravs (unregistered)

    This is the modern, fancy equivalent of the traditional

    Boolean bSucceeded = doSomething(); if(bSucceeded == true) return true; else return false;

  • Sole Purpose of Visit (unregistered) in reply to Jezor

    Or, you could just think of the "named method" as a "lamdba" and hoist the relevant parameters in from the current scope. I admit, you might have issues with Java native types (unboxed), but only if you want them to be in/out variables, which is not necessarily a good idea to begin with. The issue of "well-named functions" (such as, say, FactoryFactoryFactory) disappears if your lambda is declared locally, which of course it will be.

    I'll accept that an external (descriptively named) function is a good idea if that function is called from all over the place. In which case I would use the moral equivalent of () => WellNamedFunction(). Why Java felt the need to introduce the Class::Function syntax is beyond me, except that it sort of looks like a C++ method pointer, which might make programmers transitioning from C++ to Java happier.

    (On another note, I love optionals, or maybes, call them what you will. Unlike with nulls, it takes actual effort to ignore the absence of a result. One good thing about today's WTF is that, ugly as it is, it doesn't ignore the null result.

  • Alex (unregistered)

    Aren't Java optionals completely pointless since they can be null anyways?

  • (nodebb) in reply to Alex

    Any method that returns a null Optional is highly broken. Fix it.

  • Krzysztof Rudowicz (unregistered)

    If you have a manager saying “Readability is different for everyone, it’s fine.” in the PR, you have bigger issues than just the code.

    And yes, it is annoying to have people not understanding the features of the language and the general conventions used, but isn't that what the coder review supposed to be? We shouldn't be just blindly happy--pathing thingies and hoping it is alright in the code. We should test the solution and read the code, if possible, in the IDE and look (analyze!) what's in there. Then approve or post suggestions or block the entire PR if it doesn't meet our standards.

    This part is weird, for sure, but introducing the manager here is TRWTF here - they shouldn't get into the implementation. And maybe I'm lucky, just because my manager was a dev once upon a time and advanced because he was well suited to the position, ain't I?

  • Naomi (unregistered) in reply to Alex

    You're correct that the compiler doesn't stop you from assigning null to an Optional value, and yes, that's suboptimal. But saying that that makes them pointless is overstating it. Even a well-written, not at all WTF-y library may have reason to return null from a Widget-valued function. The same is not true if the function returns Optional<Widget>s. So, it's still legitimate to assume they aren't null unless you have to interact with deeply WTF-y code.

  • gnasher729 (unregistered)

    I'm using optionals in Swift (basically no choice), and it is impossible to dereference a null pointer like in C or C++. Calling this "$50 of material from the hardware store" is fundamentally not getting what optionals are about.

  • Future (unregistered) in reply to gnasher729

    That’s because optionals aren’t inherently broken in Swift.

Leave a comment on “Checking Your Options”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article