If statements help please?

Umekichi

Hi there,
I am currently reading the OCA Java SE 7 Programmer I Study Guide and I need help understanding an example. Here is the code:

boolean b;
boolean bValue = (b = true);
//Evaluates to true

if(bValue)
System.out.println("TRUE");
else
System.out.println("FALSE");

if (bValue = false)
System.out.println("TRUE");
else
System.out.println("FALSE");

if(bValue == false)
System.out.println("TRUE");
else
System.out.println("FALSE");

Where I am having problems with this code is the second output. Why is it false and not true?
Is it a case of bValue is now false and therefore doesn't satisfy the if meaning that it displays "FALSE"?

I know the difference between = and ==. What I don't understand is shouldn't it print "TRUE"?

Thanks in advance.

oscarBravo

Umekichi wrote: »

I know the difference between = and ==.

So what does

if (bValue = false)

do?

Umekichi

oscarBravo wrote: »

So what does

if (bValue = false)

do?

it assigns false to bValue... but since bValue is now false shouldn't it still print "TRUE"?
as bValue is now false?

Or is it a case of it's not equal to true anymore so it prints "FALSE"?

DonkeyStyle \o/

if is evaluating the success or failure of (the assignment of false to bValue). the assignment was successful, so it evaluates to true. afaik
it's the same reason why

boolean bValue = (b = true);
//Evaluates to true

makes bValue true. You could set b to false and bValue would still be true

fergalr

Umekichi wrote: »

it assigns false to bValue... but since bValue is now false shouldn't it still print "TRUE"?
as bValue is now false?

Or is it a case of it's not equal to true anymore so it prints "FALSE"?

'=' and '==' mean two completely different things.

Don't think of them as related at all.


Read '=' as 'is assigned the value of'.

Read '==' as 'is equal to' - as in 'check if this thing is equal to that thing'.

(THING1 == THING2) means 'check if THING1 is equal to THING2'. If THING1 is equal to THING2, then that entire expression (THING1 == THING2) has the value of True. However, if THING1 is not equal to THING2, then the entire expression (THING1 == THING2) has the value of False.


Think of this as being entirely unrelated to the expression (THING1 = THING2) which instead means THING1 is assigned the value of THING2.

oscarBravo

Umekichi wrote: »

it assigns false to bValue... but since bValue is now false shouldn't it still print "TRUE"?
as bValue is now false?

You're not asking whether it equals false; you're asking for the result of the expression "bValue = false", which is false, so your if statement boils down to "if (false)".

Umekichi

ohhhh, I get it now
I feel like such an idiot
Thank you very much!

oscarBravo

No problem.

I just noticed that my tagline is a reply to your sig.

fergalr

Umekichi wrote: »

ohhhh, I get it now
I feel like such an idiot
Thank you very much!

You aren't an idiot.
The decision to make the assignment operator '=', but make the test for equality operator '==' was a very bad syntax choice, made way back, which has confused generations of beginner programmers.


The example code you quote uses the result of the assignment operator.

In general, you wouldn't ever do this in Java.

The result of the assignment operator ('=') is supposed to be the value of the thing on the left, after the assignment has completed. (contrary to what DonkeyStyle said).

But don't worry about that, that's a little confusing at the start. In general, don't be worrying about the return value of assignment operators.
The most important thing is that you know and internalise the different between the assignment operator ('=') and the test for equality operator ('==').

fergalr

DonkeyStyle \o/ wrote: »

if is evaluating the success or failure of (the assignment of false to bValue). the assignment was successful, so it evaluates to true. afaik
it's the same reason why makes bValue true.

DonkeyStyle \o/ wrote: »

You could set b to false and bValue would still be true

No; it'd be false if you did that.

DonkeyStyle \o/

fergalr wrote: »

No; it'd be false if you did that.

That's true. :eek:
Wow, mixed feelings... a combination of feeling like an idiot and excitement at the new programming possibilities this opens up. :pac:

/comes to thread to school; gets school'ed

fergalr

DonkeyStyle \o/ wrote: »

That's true. :eek:
Wow, mixed feelings... a combination of feeling like an idiot and excitement at the new programming possibilities this opens up. :pac:

FWIW I think there's no shame in saying the equivalent of:

"I can program competently in Java, but I don't know what every possible line of Java does: I never write code that uses the return of an assignment, so I've no idea what the value would be."

I think that's a sensible attitude to 'knowing' a programming language (the essential attitude, if its c++ :P ).

I think 'language lawyers' who learn every obscure part of a language - even if it has no practical use to them - should instead spent their time learning a new programming paradigm, a new way of solving problems, etc.
Consequently, I think 'language trivia' interview questions are daft.

DonkeyStyle \o/

fergalr wrote: »

I never write code that uses the return of an assignment, so I've no idea what the value would be.

Yup, that's why I've never actually had that idea challenged... it's so easy to completely avoid. Although I do remember reading about it now in some introductory chapter somewhere. *facepalm*
It's all good though... I've been sampling many different flavours of humble pie on codewars.com this week. I've learned to accept my sucking in the form of intrigue.

IRLConor

fergalr wrote: »

Consequently, I think 'language trivia' interview questions are daft.

Agreed 100%. There's no value to storing arcane-but-easily-Googled data in your head.

However...

fergalr wrote: »

I think 'language lawyers' who learn every obscure part of a language - even if it has no practical use to them - should instead spent their time learning a new programming paradigm, a new way of solving problems, etc.

If you weaken "learn" to "carefully read" it's a valuable exercise. For example, the Java Language Spec is quite readable and can be very useful for understanding why parts of the language work the way they do.

You don't need to remember the lot, but I find that the stuff I do need to remember will stick in my head more if I have some idea of the underlying structure.

oscarBravo

Something I get the impression isn't being taught as well as it should is the idea of evaluating an expression. It's all too easy to get used to the idea that an "if" statement checks if one value is equal to another, or greater than it, or whatever, but in fact - in pretty much all languages I'm familiar with - it actually evaluates an expression and checks whether it evaluates to true or false.

A great word I've come across through online Python communities (although I'm sure it exists elsewhere) is "truthiness" - whether the value of an expression behaves like True or like False. Empty strings, empty lists, None, numeric zero - these all have False truthiness, whereas a non-zero number, a non-empty string and so on have True truthiness. An "if" statement checks the truthiness of the expression that follows it - that's it.

I'm not as familiar with Java as with Python, but I think it requires an expression to evaluate to a strict boolean to be used in an "if" statement. The principle still applies: when you see an "if" statement, what is the value of the expression in the parentheses that follow it? It must be either true or false.

fergalr

oscarBravo wrote: »

I'm not as familiar with Java as with Python, but I think it requires an expression to evaluate to a strict boolean to be used in an "if" statement.

As is right and proper, tbh.

I'm mostly a Python programmer these days, but Java did some things very well.

Java Language Specification wrote:

IfThenStatement:
if ( Expression ) Statement

The Expression must have type boolean or Boolean, or a compile-time error occurs.
http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.9

oscarBravo

fergalr wrote: »

As is right and proper, tbh.

I dunno. I really like being able to test for (say) a non-empty list returned from a function:

my_list = make_list()
if my_list:
    do_something_with(my_list)
else:
    ...

It just makes for much neater code (to my eye) than:

my_list = make_list()
if my_list != []:
    ...

Plus it allows make_list() to return None rather than an empty list and still works. Each to their own, I guess.

The wider point is that an "if" statement evaluates the truth of the expression it's testing, and remembering that makes for easier debugging.

onemorechance

Java has null, so for example your list could be in three states: null, not-null and empty, or not-null and not empty.

oscarBravo

onemorechance wrote: »

Java has null, so for example your list could be in three states: null, not-null and empty, or not-null and not empty.

In Python, an empty list and None both have false truthiness, so my first example works either way.