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.
