There's definitely closures here. They're just hiding, if you don't know
where to look!
Here's one...
val b = a flatMap {getBFrom}
which is point-free notation for
val b = a flatMap {getBFrom(_)}
Which, in turn, is just syntactic sugar for
val b = a flatMap {x => getBFrom(x)}
So that's your desire for reduced punctuation nicely taken care of :)
On 27 July 2012 12:09, Ricky Clarkson <[email protected]> wrote:
> Without a => it's not a closure. I find it confusing sometimes to have
> extra punctuation; I keep thinking I'm missing something. return (x + 5);
> bugs me in Java too :)
> On Jul 27, 2012 8:05 AM, "Kevin Wright" <[email protected]> wrote:
>
>> 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.
