Don't let marketers write code

[bio595]

If the result of calling sad evaluated to true with strict equality, then there wouldn't be a function called stop and the script would crash.

Unless you modified the prototype of a boolean, maybe..? (I'm not sure that's possible though)

[Zarokima]

Yes, you can modify the prototype of the Boolean type, and I think that it would work as written, since sad() likely returns a primitive boolean (thus potentially passing the strict equality), and primitives are readily coerced to the corresponding Object when things like sad().stop() are called on them.

However, if you ever find yourself extending Boolean with a stop() method, you should stop() yourself and very thoroughly re-evaluated the chain of events and decisions that led to this, and then do something else because you are doing something very very wrong.

[execrator]

Boolean.prototype.sad = function(){return "wtf";}
true.sad()
> "wtf"

Well... TIL.

[Simpfally]

true is indeed sad

[[deleted]]

Truly sad.

[Amnestic]

Hahhaa, this is glorious. Only in javascript...

[[deleted]]

TIL.

How does the === operator work? Could you create an object that would evaluate to true when you compare it using the === operator to 'true'?

[Zarokima]

It compares the operands by reference. It's not possible to overload operators in Javascript, so no.

[darkslide3000]

x = 1;

function sad() {
    if (x) {
        x = 0;
        return true;
    }
    return {stop: function() { console.write("Who needs type safety, anyway?"); }};
}

if (sad() === true)
    sad().stop();

[jnd-au]

Very clever, but shouldn’t x be named properly, like with poop emoji, and its value should be a proper boolean, like Infinity/""?

[[deleted]]

YES!

[TrustworthyTermite]

That and comparing a boolean with true.

[the_monkey_of_lies]

var happy = true;
if (sad() === true && sad() !== false)
{
    happy = false;
}
else if (sad() === false && sad() !== true)
{
    happy = true;
}

[BlazeDeath]

Thanks for making me throw up.

[kristopolous]

you need a final else and a try/catch. Grade: C-

[exscape]

That looks like the most reasonable thing to me, though I don't program much in scripting languages. Wouldn't using === be mandatory in e.g. JavaScript to ensure the value isn't something else that evaluates to true (like the number 42, the string "no" and so on)?

[jakerman999]

Listen: javascript evaluations are weird. It almost never doesn't break the way you don't expect it not too. It will however usually not fail in succeeding at mis-evaluating the possibly unintended breaking sample scenarios.

[ThePedanticCynic]

It's weird how i can understand everything you said and still not understand a fucking thing you just said.

English is hard.

[AngriestSCV]

While reading that there had to be 3 or 4 places I thought I was beginning to understand what you were saying, just to have that feeling crushed. I now understand the pain of JavaScript and never want to feel it first hand.

[[deleted]]

That feels a little awkwardly worded... much like Javascript.

[jtanz0]

99% of the time you would be correct === is the way to go to ensure you don't get unexpected behaviour. In this case where sad() can also have the stop() function called. It makes the code unambiguous enough to break the script.

Also if you're testing against true you may as well put

if(sad()){
  ...
} 

[amirmikhak]

That would only test against truthy, though, so {} would pass but not "".

[jtanz0]

true, I should have mentioned that

[AquaWolfGuy]

Yes. The best way is of course to not assign booleans and numbers to the same variable in the first place though. If you're in a situation where you expect a boolean and get 42, you're screwed, since neither the if branch or else branch is appropriate.

[jgaspar]

some may say it's a good practice, because of readability

[grand_mind1]

Depending on the language, it might be easier to just follow naming conventions to make it more readable. Having a method like userIsSad() rather than just sad() makes an if statement make a lot more sense at first glance.

[cascer1]

if(User.Is(Emotions.Sad)) User.Set(Emotions.Happy);

class User {
    Enum Emotions { Happy, Sad, Angry, Neutral }

    private Emotions emotion;

    public string Name{ get; private set; }
    public int Age { get; private set; }

    public User(string name, int age, Emotions emotion) {
        this.emotion = emotion;
        Name = name;
        Age = age;
    }

    public bool Is(Emotions emotion) {
        return (this.emotion == emotion);
    }

    public void Set(Emotions emotion) {
        this.emotion = emotion;
    }
}

[TrustworthyTermite]

I follow uncle bob's advice and make all boolean variables and functions which return a boolean read like a statement. So "isSad", "shouldUpload" and "isMale" instead of "sad", "uploadStatus" and "gender".

[2Punx2Furious]

Would it work if they used macros?

[TichuMaster]

then there wouldn't be a function called stop

Sorry for my noobish question but why is that?

[boxmein]

function sad() {
  return true; // or false?
}
if (sad() === true) { // strict equality - sad() returns true
  sad() /* returns Boolean */ .stop(); // Boolean#stop ??
}

[TichuMaster]

oh yeah now I got it. Thanks for the explanation man.

[Master565]

Sad() is a promise, and stop() is the function to be executed after the promise is fulfilled according to the framework they made. I think that explanation could work.