I was elated and horrified to see the scope of functional programming covered in Chapter 4 in Jeanne and Scott's book.
Horrified, because there was so much in there.
Then elated, because I want to know all that stuff anyway, so now I have an excuse to tell my wife, next boss, etc.-- thank you OCJP.
Anyway, both the book and a tutorial video I watched were a bit skimpy on details of how .and() and .or() really worked.
I had two questions immediately upon seeing them:
a. Short Circuit or Not?
b. Do we get the equivalent of operator precedence so that just chaining .and() and .or() is the same thing as writing expressions with && and || ?
A quick glance at the docs told me "Yes" for the first part. Not quick enough, I had already written noisy methods to demonstrate the answer to (a) visually.
I stared at it until I was going cross-eyed, and couldn't tell the answer to (b) from the docs. It seemed like it would potentially be possible to do, but beyond what an API would be expected to do. So my guess was "No" for part B but after reviewing the tutorial video and the chapter material it seemed to still be ambiguous.
I threw together the following quick little demo to show the answer to (b). It does make use of method references as well, primarily because I wanted to be able to have a "noisy" version that illustrated the calls (commented out below). It looks like this:
Literally, just walking away from this I couldn't remember where it made a difference, but knew it did.
This program highlights the difference between the normal short-circuit expression:
T || F && F ==> T
and the composed predicate:
T.or( F ).and( F) ==> F
I don't know if this is quite in scope for the 819 exam or not, but my brain wouldn't let me focus on other things until I understood the answer to by doubt in (b) anyway.
Lastly, I threw in a neat convenience static method new to Java 11+ at the end, to prove I read the docs. It took me a little while to figure out exactly how to call it.
I think it makes more sense and results in more literate code. The old way of reversing the polarity of a complex predicate combination was clear and readable, NOT!
Oh wait, that is already a nerdy joke trope, no doubt suggesting the static convenience method we got in Java 11.
Comment it out if you are running with Java 8, 9 or 10.
So my confusion can be summarized thusly.
When I heard "predicate combination with .or() and .and() short circuits"
I thought....great, that can save a lot of time, since....
true || false && false && false && false && false && false && false
just evaluates to true without testing the other N conditions...
it sounds like maybe:
is gonna do the same thing for me! They said "short circuit, right?"
Putting my noisy predicates back in, I see that I over-estimated what short-circuit means, the scope of short-circuit is limited to pairwise comparisons, different to "normal expressions with operators":
Yields of course, because I *was* confused:
You were confused by what short-circuit meant with chained predicates!
The precedence that || and && have doesn't carry over to chained predicates, so short-circuit means less than I thought.
I get it now, but there's no way it would have got into my thick skull from two presentations and a read of the docs.
I normally use parentheses liberally to avoid confusion, as mentioned in other threads, but on the exams they are treated like rare, valuable commodities to ensure we really understand the order of precedence.
Sure a.plus(b).times(c) is the same as (a + b) * c
but the promise of "short-circuit evaluation" made me think that something different was going to happen with predicate chaining.
I feel that now that I understand that in the case of Predicate Chaining, (but not normal boolean expressions) short-circuiting is limited to a single invocation of .and() or .or() I don't need it anymore.
That may help someone else who might be sharing the same confusion that I had in the future, tho.
Even as a kid, I'd get the hardest questions on the test right and be stumped on the easiest ones, so maybe it is just me.