On 30 July 2012 01:24, Reinier Zwitserloot <[email protected]> wrote:
> Actually, this flatMap snippet shows exactly why it's a horrible fit for
> java. This introduces the concept of flatMap which is a gigantic can of
> worms. Yes, people who are used to functional languages find this as
> obvious and effortless to read, write, and understand as a java programmer
> who sees 'while'. It's an entirely different way of thinking, a _HUGE_
> mental burden.
I disagree about the burden. As concepts go, it's certainly no more
challenging than polymorphism, or any of the GoF patterns that you'd take
for granted as knowledge in any half-decent Java programmer. It's also a
great deal simpler to understand than IoC/Dependency Injection.
> You are not Joe Java. Joe Java does not read this and instagrok what's
> going on here. This is a problem. A show-stopper, even.
>
Hey! Let people decide for themselves what they can and cannot understand!
It's incredibly patronising to say to the Java community at large "Don't
bother learning XYZ, it's show-stoppingly difficult and you'd never
understand it".
In my experience, most programmers are rather intelligent, and can easily
take this stuff in their stride if given a chance.
> Any language proposal to hoist nullity into the type system surely should
> also come with various useful riders attached, such as elvis operators and
> the like. Then the code snippet becomes something Joe Java would, in fact,
> grok just fine:
>
> A? varAMightBeNull = methodThatMayProduceA();
> B? varBMightBeNull = varAMightBeNull.?getB();
>
>
> note that your code snippet involves a static method call called
> 'tryToGetBFromA', which can _OF COURSE_ check if the incoming param is null
> and if so, return null.
>
It could be another method in the same object. Nothing demands that the
thing be static.
> So, your actual snippet doesn't even _NEED_ option. I'm not sure if you
> did this because you are just not aware of what idiomatic java looks like,
> or if you had to write extremely convoluted java code in order for your
> flatMap example to work.
>
It's possible, but it also means that null-checking needs to be introduced
at multiple levels in your software stack. Almost every method in your
system would have to perform this data sanitisation. That's a lot of
boilerplate to be sprinkling around so liberally, and is the sort of
mindless repetition that just cries out for the occasional human error.
Just because something is idiomatic, does that make it right? Or even the
best way? Idioms should be allowed to change and evolve.
> I don't know the specific of flatMap, but I'm guessing that, if
> tryToGetBFromA was a no-args instance method, your flatMap wouldn't work as
> written.
>
It wouldn't. flatMap works with functions. Ideally pure functions
(referentially transparent, no side-effects, only work with input supplied
via their parameters, and *always* return the same output when given the
same input)
Then again, a great many other things also wouldn't work if tryToGetBFromA
was a no-arg instance method. It would have to grab an instance of a from
the context of the surrounding object. This instance would then have to be
mutable, and would change every time the snippet was executed.
You'd run a high risk of having other methods begin using this instance
that was never intended to be shared, and making the thing
non-deterministic. Unit tests would certainly be a lot harder to implement
and you would most definitely not be thread safe.
SimpleDateFormat took this approach. You *must* use a different instance
on different threads unless you want to get some very confusing output, yet
the thing is also incredibly expensive to create, so you really don't want
to be creating instances on demand.
Such a design forces people to:
- Be exposed to errors that they can't understand
or
- Unnecessarily complicate their code with ThreadLocals as a workaround
or
- Just decide it's a stupid design anyway and go with Joda Time
I imagine that you'd be hard-pressed to find anyone who holds this up as an
example of how things ought to be done.
>
> On Friday, July 27, 2012 2:30:17 AM UTC+2, clay 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.
