doSomethingIfAWasAbsent() and doSomethingIfBWasAbsent() are clearly impure, side-effecting methods. The fact that we're not using any return values is a dead giveaway!
By convention they *should* have the empty param block to indicate this. Always using braces around a closure is more of a personal convention. Just like the parentheses around the conditions in the Java code, I find it helps readability my more clearly delimiting the intent of the code. On 27 July 2012 11:32, Ricky Clarkson <[email protected]> wrote: > I meant in the Scala code but forgot to say so. Also, blocks can't be > part of expressions in Java like in Scala so your Java code won't compile. > On Jul 27, 2012 7:25 AM, "Kevin Wright" <[email protected]> wrote: > >> I think you do for the (a==null) check, because there are two statements >> against the failure condition (the assignment to b, and the second check). >> if a is absent, then neither doSomethingIfBWasAbsent nor doSomethingWithB >> should be called! >> >> The second block can go though, and taking advantage of precedence for == >> gives: >> >> final A a = getA(); >> a == null ? doSomethingIfAWasAbsent() : { >> final B b = getBFrom(a); >> b == null ? doSomethingIfBWasAbsent() : >> doSomethingWithB(b); >> }; >> >> Though my personal preference would be to retain the bracketing for the >> equality checks, I find it easier to read that way. Past exposure to LISP >> may have some influence on this though :) >> >> >> On 27 July 2012 11:09, Ricky Clarkson <[email protected]> wrote: >> >>> Kevin, I believe you don't need any of the (){} characters there, but >>> maybe I'm missing something. >>> On Jul 27, 2012 6:04 AM, "Kevin Wright" <[email protected]> >>> wrote: >>> >>>> That's a bit open-ended, are you thinking of a particular construct >>>> that you think would be challenging to convert? >>>> >>>> As another trivial example, something like this: >>>> >>>> final A a = getA(); >>>> if (a != null) { >>>> final B b = getBFrom(a); >>>> if (b != null) { >>>> doSomethingWithB(b); >>>> } else { >>>> doSomethingIfBWasAbsent(); >>>> } >>>> } else { >>>> doSomethingIfAWasAbsent(); >>>> } >>>> >>>> >>>> Or with the tertiary operator: >>>> >>>> final A a = getA(); >>>> (a == null) ? doSomethingIfAWasAbsent() : { >>>> final B b = getBFrom(a); >>>> (b == null) ? doSomethingIfBWasAbsent() : { >>>> doSomethingWithB(b); >>>> } >>>> }; >>>> >>>> >>>> Could be written in Scala as: >>>> >>>> val a = getA >>>> val b = a flatMap {getBFrom} >>>> a getOrElse {doSomethingIfAWasAbsent()} >>>> b getOrElse {doSomethingIfBWasAbsent()} >>>> b forEach {doSomethingWithB} >>>> >>>> >>>> >>>> >>>> >>>> On 27 July 2012 04:16, Cédric Beust ♔ <[email protected]> wrote: >>>> >>>>> Yes but that's the most trivial case. For example, experiment with >>>>> your Option code when the original code has else's. >>>>> >>>>> -- >>>>> Cédric >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 26, 2012 at 5:30 PM, clay <[email protected]> wrote: >>>>> >>>>>> Here is a simple example that illustrates the benefit of Option >>>>>> beyond avoiding null exceptions: >>>>>> >>>>>> Here is a traditional piece of logic using traditional null >>>>>> if-checks. This is using Scala syntax but would be equivalent in Java. >>>>>> >>>>>> val variableAMayBeNull: A = methodThatMayProduceA(); >>>>>> if (variableAMayBeNull != null) { >>>>>> val variableBMayBeNull: B = tryToGetBFromA(variableAMayBeNull); >>>>>> >>>>>> if (variableBMayBeNull != null) { >>>>>> doSomethingWithNonNullB(variableBMayBeNull); >>>>>> } >>>>>> } >>>>>> >>>>>> Same logic using Option. This is Scala syntax. Java can do this but >>>>>> not as nicely until it gets lambdas. >>>>>> >>>>>> val variableAMayBeNull: Option[A] = methodThatMayProduceA(); >>>>>> val variableBMayBeNull: Option[B] = >>>>>> variableAMayBeNull.flatMap(tryToGetBFromA); >>>>>> variableBMayBeNull.foreach(doSomethingWithNonNullB); >>>>>> >>>>>> Both blocks are logically equivalent, but the Option route is much >>>>>> more concise, elegant, and maintainable. The if-logic is moved from the >>>>>> end >>>>>> application code to inside of the Option class. Since this type of logic >>>>>> is >>>>>> so common in application code, the code simplification benefits are quite >>>>>> large. >>>>>> >>>>>> >>>> >> -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
