Unit 5 Stage 8 (===)

CS Principles Unit and Lesson Discussion
,
1

My students are getting warnings that they should have three (===) equal signs to compare in App Lab Stage 8. Can someone explain why this is? (I am used to Java/C++ where comparison is two (==).

2

@sklug

The simple answer is that == does type conversion of the values being compared and === does not. So for === ,the value and the type must match. For example, if
var x = 15;
then,

x==15; //true
x==“15”; //true
x===15; //true
x===“15”; //false type mismatch

Andrea

3

This double-equal v. triple-equal thing in JavaScript is dastardly for the first time learner because they are unlikely to need or notice the difference between the two.

@anmrobnott is right about the difference. The == is said to be “coercive” - it will try its best to figure out what you’re trying to compare. Often this is convenient, especially when user input is involved, because you don’t have to do as much type conversion by hand. The === is the strict equality operator you’re probably more familiar with from languages like Java/C/C++ etc.

To help with data type issues, you should know that App Lab has numeric equivalents for operators that typically return strings.

prompt("message");    // pop up input message, return user input as string
promptNum("message"); // pop up input message, force user to enter number, return it

getText(id);   // get value out of UI element as string
getNumber(id); // attempt to convert value in UI element to numeric type

In most cases for this course == is fine. If you want the gutter warnings to go away, just make it a === and it likely won’t make a difference. One place === might bite you is this case where you’re maintaining a variable as a number, but use getText to compare it to value you extract from the UI. e.g.

var score = 10;

if( getText('scoreLabel') === score){
   //game over
}

In this case if scoreLabel happens to have “10” in it, getText returns the literal string “10” which when compared with the number 10 via === will evaluate to false.

Hope this helps

Baker
CSP Team

2 Likes
4

I seem to be stuck on Stage 8, bubble 9. I’ve attached a sample of my code. Could anyone shed more light on why this isn’t working or what do I need to change / add for this to operate correctly? Thanks in advance!

var password_input = “GoPackGo”;
if (getText(“password_input”) == password_input) {
onEvent(“login_btn”, “click”, function() {
showElement(“unlock_img”);
hideElement(“lock_img”);
});
}

5

@nick.bahr First of all, I LOVE your password! :cheese:

It looks like your event is nested inside your if statement. I needs to be the other way around like this:

var password_input = “GoPackGo”;
onEvent(“login_btn”, “click”, function() {
if(getText(“password_input”)==password_input){
showElement(“unlock_img”);
hideElement(“lock_img”);
}
});

The If statement runs when you hit run on the program. At that point, there is no input so it does not execute the rest of the code and is not listening for the event at all. If you put the event handler outside and the if statement inside, then it will check the if statement when the event occurs. Hope that helps!

1 Like
6

Hi @baker -
My students just discovered this issue and your explanation above makes sense. However, we’re wondering why App Lab generates a warning for the following code. There is no type conversion yet a warning is still issued.

var count = 0;

if (count == 0)
{
console.log(“zero”);
}

App Lab warns Use ‘===’ to compare with ‘0’;

Interesting that if I change the code to the following (which is not the intention, we want count to be an int):
if (count == ‘0’) // compare count with a char silences the warning
the warning goes away.

Any insight here?

Thanks

7

Welcome to JavaScript!!!

The == is a more permissive equality comparison operator - it will try to coerce the datatypes of the values on either side to be the same and then compare the values. === is not permissive - it forces both the type and the value to match.

Here is a simple console example that shows this in action - compare an integer with the stringified form of it:

> 0 == "0"
< true
> 0 === "0"
< false

Some years later people thought that having these different operators was a bad idea or leads to bad practice. So these days people say you should “never” use the double-equal (but read below). AppLab uses a 3rd-party code editor library that by default throws up a warning whenever you use == in effect to say “are you sure you know what you’re doing?” It doesn’t affect the program at all - warnings are not errors. We unfortunately haven’t figured out a way to fix or suppress that warning in a way that doesn’t break other things. It’s on the list though - and I’ll take it into advisement that we could have a curricular approach to letting students know it’s okay to have a warning.

When writing the curriculum we decided to use the == for a few reasons:

(1) at the time - and still to some degree - students will want to naturally compare mixed types, for example integers with stringified versions of integers, because they might ask the user to type a number into a text box. That number comes into the program as a string, like this:

if ( getText("txtBox") == 16 ){
   ....
}

(2) What’s SUPER messed up is that the other comparison operators are permissive too, and they DON’T have non-permissive versions. For example (hold onto your brains):

> 5 > "0"
< true
> 5 >= "0"
< true

And so it’s equally plausible that a student would want a similar if-statement to the one I showed above that uses an inequality operator, like so:

if ( getText("txtBox") > 16 ){
   ....
}

(3) Therefore, we thought it would be easier to present the set of standard comparison operators that exist in most languages:

==
!=
>=
<=
<
>

Since for most plausible student cases, when they are learning, the permissive == gets the job done. This would also prevent us from having to teach students how to parse strings into their correct types. for example:

if ( Number(getText("txtBox")) === 16)){ ... }

Doing type conversions and dealing with issues around strong typing seemed beyond the scope (or value) of a CSP course. So we didn’t want to muddy the waters even more. As a programmer you only really get into trouble when comparing complex types (objects) if you don’t know the difference between them.

Hope this helps,

-Baker
CSP Team

2 Likes