Is it alive? No. But wait... Yes!

Nice, I wonder how "isDead" is implemented though...

Nice, I wonder how "isDead" is implemented though...

It just returns isDead boolean variable lol!

This sounds like something my friend would made on a regular basis XD

This is the class implementation for Schrodinger's cat.

hahaha Bacterius, good one!

amazing function, lets always return true! :)

On first read, I actually thought it did what it was supposed to. That is amusing, though. I always wonder when people give a variable an initial value, before assigning a value to it in all possible branches.

That is amusing, though. I always wonder when people give a variable an initial value, before assigning a value to it in all possible branches.

It's more foolproof in case you forget to initialize it later. It ensures the variable can't be used with an undefined value no matter what.

Also, compilers will complain if you don't do this. Most of the time they will detect if it's guaranteed to get initialized later (in which case they won't emit a warning), but in some cases they may fail to realize it (and in some cases it's guaranteed but it relies on code from outside which means the compiler outright can't tell).

Nice, I wonder how "isDead" is implemented though...

Why, the implementation of isDead() is obvious!

 
public boolean isDead() {
    boolean dead = false;
    
    if(isAlive() == true) dead = isAlive();
    if(isAlive() == false) dead = !isAlive();
 
    return dead;
}
 

And if you feel that is just leaving Schrödinger's cat in the box:

 
 
public class Critter {
 
    // Given
    public boolean isAlive(){
        boolean alive = false;
        
        if(isDead() == true) alive = isDead();
        if(isDead() == false) alive = !isDead();
     
        return alive;
    }
 
    private boolean dead = false;
 
    private int counter = 0;
    
    private boolean isDead() {
        if(dead) {
            ++counter;
            return dead && counter % 2 == 0;
        }
        return dead;
    }
    
    public void squish() {
        dead = true;
    }
 
}
 

Now we can take our critters for a quick spin:

 
 
public class Main {
 
    private static String describeStatus(Critter critter) {
        return critter.isAlive() ? "very much alive" : "a little worse for wear";
    }
    
    private static String describeStep() {
        double random  = Math.random();
        if(random < 1.0 / 3.0) {
            return "Squish!";
        } else if(random < 2.0 / 3.0) {
            return "Squelch!";
        }
        return "Crunch!";
    }
    
    public static void main(String [] args) {
        Critter critter = new Critter();
        System.out.println("What a lovely little critter! I sure hope nothing happens it!");
        if(Math.random() < 0.5) {
            System.out.println(describeStep());
            critter.squish();
            System.out.println("Oh dear, I accidentally stepped on it. Poor thing is looking " + describeStatus(critter) + " now...");
        } else {
            System.out.println("Close call, I narrowly avoided it. It is looking " + describeStatus(critter) + " now...");
        }
    }
    
}
 

I hate it when I find actual code which looks not unlike this, bugs in one area worked around by equally crazy stuff somewhere else.

And if you feel that is just leaving Schrödinger's cat in the box:

 
 
public class Critter {
 
    // Given
    public boolean isAlive(){
        boolean alive = false;
        
        if(isDead() == true) alive = isDead();
        if(isDead() == false) alive = !isDead();
     
        return alive;
    }
 
    private boolean dead = false;
 
    private int counter = 0;
    
    private boolean isDead() {
        if(dead) {
            ++counter;
            return dead && counter % 2 == 0;
        }
        return dead;
    }
    
    public void squish() {
        dead = true;
    }
 
}
 

i'm curious if you intended the counter to actually be useful in making sure isAlive return the correct result?

edit: actually, after re-reading the code several times, i'm not sure if it does actually fix it.

edit2: you'd use a pre-increment on it's own line? i tend to stick to post-increments if it's on it's own line.

edit2: you'd use a pre-increment on it's own line? i tend to stick to post-increments if it's on it's own line.

Some programmers see postincrement as a no-no, especially because of the behavior of some standard classes with those operators in some cases (don't remember the exact details)... Postincrement does look nicer in the source code though.

i'm curious if you intended the counter to actually be useful in making sure isAlive return the correct result?

edit: actually, after re-reading the code several times, i'm not sure if it does actually fix it.

Fix is almost certainly the wrong word for that code. If my attempt doesn't actually cause the resulting program to "work", then please take it that this was intended as hilarious commentary on how such band-aids often fail to achieve what they set out to do. I, umm, I'm sure I must have meant it that way...

edit2: you'd use a pre-increment on it's own line? i tend to stick to post-increments if it's on it's own line.

I generally avoid using the increment operators as part of more complex expressions, and I use pre-increment due to auto-pilot from writing loops. Thanks to spending a bit of time with Ruby, I wouldn't mind switching to += 1, at least for integers.

edit2: you'd use a pre-increment on it's own line? i tend to stick to post-increments if it's on it's own line.

Pre-increment is never slower than and sometimes faster than post-increment.

Postfix creates a copy of the original value which takes a small bit of extra time.
However when it is on its own line and is its own statement, the copy is nothing more than an address of a temporary or a register, but no instructions to actually act upon it, which makes it impossible for any compiler to generate code to reference it, and without it being referenced any compiler written within the last 276.45 (as of the time of writing) years will also omit the copy operation itself, leading to equivalent code either way.

However, in general, you should prefer prefix when possible, even on its own line, if for nothing more than the practice and consistency.


L. Spiro