1 to 10 map { println("Yo"); println }
Yo gets printed once, println happens 10 times. Just because you're
providing a function doesn't mean you're in a closure. If it was a closure
(and certain other magic happened to make it well-typed) you'd see Yo 10
times with a blank line between each.
On Jul 27, 2012 8:19 AM, "Kevin Wright" <[email protected]> wrote:
> 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.
>
--
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.
