Random Questions

Ikatono

Arkham Horror is a seven hour committee meeting. Do not get. I dislike Ascension and would recommend not getting it, but its not as painfully bad.

The problem with coop games is if there's no hidden information, there's essentially one player. If there is hidden information (from other players) then you're constantly trying to figure out how to get it across.

Pegu

This is probably a naïve question, but why don't if statements have finally statements like try-catches do. I've often had code that does one thing if a happens, another if b happens and something that should happen if either happen. I end up with pretty wet (not following the DRY principle) code that looks like this.

if (a) {
//code specific to a
//final code for both
}
elif (b) {
//code specific to b
//final code for both
}
This can be mildly improved with this

void finalCodeForBoth() {
//final code for both
}
if (a) {
//code specific to a
finalCodeForBoth();
}
if (b) {
//code specific to b
finalCodeForBoth();
}
but that's still a bit wet and ugly.

You could also do this

if (a) {
//code specific to a
}
elif (b) {
//code specific to b
}
if (a || b) {
//final code for both
}
but that gets pretty messy if you have a lot of complicated conditions. I might be wrong about this but it also appears to require a and b to be re-evaluated.

I think something like this makes a lot more sense.

if (a)
//code specific to a
elif (b)
//code specific to b
finally
//final code for both
Why doesn't this exist? I understand if statements aren't the end-all-be-all but this still seems like a simple feature that could clean up code and resources of a common language construct.

PS: Why does <code> either leave a space like

this {
//indented
}
or fuck up my indentation like
this {
//indented
}

trogdor9

if (a) {
//code specific to a
}
elif (b) {
//code specific to b
}
if (a || b) {
//final code for both
}


You could store your conditions in boolean variables to avoid your code getting messy and repetitive:
boolean a = !x && y;
boolean b = x && z;
if (a) {
//code specific to a
}
elif (b) {
//code specific to b
}
if (a || b) {
//final code for both
}

Apreche

Why not just do this?


a = !x &&
b = x && z;

if a:
f(a);
elif b:
g(b);
final();

Pegu

if (a) {
//code specific to a
}
elif (b) {
//code specific to b
}
if (a || b) {
//final code for both
}


You could store your conditions in boolean variables to avoid your code getting messy and repetitive:
boolean a = !x && y;
boolean b = x && z;
if (a) {
//code specific to a
}
elif (b) {
//code specific to b
}
if (a || b) {
//final code for both
}

That still doesn't help much if you have many conditions

if (a || b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z) {
//final code for all the things
}
but I guess you're not supposed to have that many conditions anyways.

Pegu

Why not just do this?


a = !x &&
b = x && z;

if a:
f(a);
elif b:
g(b);
final();

final() executes if neither a or b return true.

Apreche

Why not just do this?


a = !x &&
b = x && z;

if a:
f(a);
elif b:
g(b);
final();

That executes if neither a or b return true.

Oh, then I would actually do it like this, which is only slightly different from what trogdor did.

if (a or b):
    if a:
       # do A
    if b:
        # do B
    # do finally thing

This also doesn't make the false assumption that b and a both can't be True siiiimultaneously.

trogdor9

That still doesn't help much if you have many conditions

if (a || b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z) {
//final code for all the things
}
but I guess you're not supposed to have that many conditions anyways.

You missed the point.
boolean a = b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z;
if (a) {
//final code for all the things
}
//other ifs and elses and stuff

Apreche

To make a broader point, this kind of code usually only happens when inheritance is not used, or not used properly. Code could look like this.

class P(Object):
    def do_thing(self):
        # default/finally behaviour

class A(P):
    def do_thing(self):
        # do A-specific thing
        super(A) # will cause the default/finally behavior to happen

class B(P):
    def do_thing(self):
        # do B-specific thing
        super(B) # will cause the default/finally behavior to happen

#now pretend x is a collection of instances of class P, which could be As or Bs or Ps.

for things in x:
    x.do_thing();

No if statements at all. That is the object oriented way. That is why dynamic and object oriented languages are often lacking the switch/case/finally/default statement.

Pegu

That still doesn't help much if you have many conditions

if (a || b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z) {
//final code for all the things
}
but I guess you're not supposed to have that many conditions anyways.

You missed the point.
boolean a = b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z;
if (a) {
//final code for all the things
}
//other ifs and elses and stuff

I understand boolean variables and see how your solution can help but I still think

finally {
//final code for all the things
}
is better than both

if (a || b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z) {
//final code for all the things
}
and

boolean a = b || c || d || e || f || g || h || i || j || k || l || m || n || o || p || q || r || s || t || u || v || w || x || y || z;
if (a) {
//final code for all the things
}

Linkigi(Link-ee-jee)


if(a || b)
{
if(a)
f(a);
else
g(b);
final();
}
But again, that's kind of messy. If you have a whole group of variables (and need final code for different groups), consider just having extra booleans as flags for certain cases.

Pegu

To make a broader point, this kind of code usually only happens when inheritance is not used, or not used properly. Code could look like this.

class P(Object):
    def do_thing(self):
        # default/finally behaviour

class A(P):
    def do_thing(self):
        # do A-specific thing
        super(A) # will cause the default/finally behavior to happen

class B(P):
    def do_thing(self):
        # do B-specific thing
        super(B) # will cause the default/finally behavior to happen

#now pretend x is a collection of instances of class P, which could be As or Bs or Ps.

for things in x:
    x.do_thing();

No if statements at all. That is the object oriented way. That is why dynamic and object oriented languages are often lacking the switch/case/finally/default statement.

I understand if statements aren't the end-all-be-all

I do see how my if, elif, finally thing wouldn't be that useful because it asserts that a and b are not both true and I guess an additional long if statement is better than that. I hadn't given much thought to elif being "ifThisOtherThingDidn'tHappenButThisDid" and was using it as more of an "otherRelatedIf"

lackofcheese

First of all, that doesn't really match up with the logical conception of what a finally block does, because the finally block for a try-catch-finally is supposed to execute pretty much no matter what, which doesn't correspond to your version that triggers only if one of the if blocks did.

The object-oriented approach suggested by Scott works OK here, though I don't think object-orientation is the solution to each and every problem and it's not necessarily a good idea for this type of thing.

However, if you were to have an example with 26 many different conditions, that is definitely the kind of situation where an if statement doesn't seem like the right solution anyway, and OO solutions and the like start to look better.

On the other hand, if your conditions are in fact not mutually exclusive, as others have said, the best idea is probably something like Scott's:

if (a or b):
    if a:
       # do A
    if b:
        # do B
    # do finally thing

This also doesn't make the false assumption that b and a both can't be True siiiimultaneously.

The alternative is something like this:

finally_needed = False
if a:
    # do A
    finally_needed = True
if b:
    # do B
    finally_needed = True
if finally_needed:
    # do finally thing

which is, I think, Linkigi's second suggestion.

On the whole, this is a situation where I would have to see the specific example before I could tell you what I think the best way to do it would be.

Pegu

However, if you were to have an example with 26 many different conditions, that is definitely the kind of situation where an if statement doesn't seem like the right solution anyway, and OO solutions and the like start to look better.

On the whole, this is a situation where I would have to see the specific example before I could tell you what I think the best way to do it would be.

Luckily I don't have such a gimped example and was speaking theoretically. I thought this construct could help clean up a bit of code but didn't realize it introduced the problem of mutual exclusivity.

Pegu

The alternative is something like this:

finally_needed = False
if a:
    # do A
    finally_needed = True
if b:
    # do B
    finally_needed = True
if finally_needed:
    # do finally thing

which is, I think, Linkigi's second suggestion.

That's the same as

void finalCodeForBoth() {
   //final code for both
}
if (a) {
   //code specific to a
   finalCodeForBoth();
}
if (b) {
   //code specific to b
   finalCodeForBoth();
} 

isn't it?
Edit: I guess this would execute the final code twice in the case of both being true where Linkigi's wouldn't.

Apreche

I agree object orientation is not a solution to every, or even most, problems. I was just demonstrating how projects that make use of inheritance greatly reduce the need for complex conditional structures in a general sense. To figure out whether it is the right answer in this case would require a lot more context.

lackofcheese

Edit: I guess this would execute the final code twice in the case of both being true where Linkigi's wouldn't i.

Precisely.

I just worked out how to do what you originally wanted (i.e. in situations where they are in fact mutually exclusive).

condition_met = True
if a:
    # do A
elif b:
    # do B
elif c:
    # do C
else:
    condition_met = False

if condition_met:
    # do finally thing

I think that's the cleanest solution.

Apreche

I just worked out how to do what you originally wanted (i.e. in situations where they are in fact mutually exclusive).

condition_met = True
if a:
    # do A
elif b:
    # do B
elif c:
    # do C
else:
    # condition_met = False

if condition_met:
    # do finally thing

SNAP

Pegu

SNAP

MATATAT

lack's solution or Scotts is best. Otherwise alternate solutions would if to have if's then another function that determines if a || b. You could do it other ways. The problem being that your code is just focusing on what you mostly find "aesthetically pleasing". Neither offers much in the way of efficiency. Ideally depending on how much work your finally needs putting it all in the same code block would be best, but honestly probably not the best for readability. I try to avoid nesting as much as possible because it severely limits readability. I feel similarly about multiple if statements.

The main thing you should consider is segregating unique computations into their own functions/methods. Personally I think this does the most for readability and comprehension.

trogdor9

...and lackofcheese wins the thread.

SNAP

MATATAT

I can dig it.

ninjarabbi

Any good ideas for a homemade recoil pad?

Jack Draigo

My work shoes are coming apart at the seams, so I need some new ones. I want a pair of work boots. Anyone know of a reasonably priced (no more than $60) pair of reliable boots? Also need them to be black.

Jack Draigo

Nevermind I just ordered these: http://www.magnumboots.com/us/product-spider-5-1-urban-black.html . Thoughts?

Sail

These weird little jagged lines have shown up in the corners of all my Firefox windows, but no other windows. At first I thought they were dead pixels, until I tried dragging the window around. Any idea what this is?

Churba

Nevermind I just ordered these: http://www.magnumboots.com/us/product-spider-5-1-urban-black.html . Thoughts?

Looks decent enough.

Victor Frost

Looks like claw marks. 'Swhat happens when you keep a fox.

open_sketchbook

Anyone else here who does 3d stuff; are there any good tutorials or resources out there for doing really low-poly character models? I'm talking like, Quake 3-ish era.

Anthony Heman

I realize states do this differently, but I just renewed my drivers license and either I can't see well at all or I was using the thing improperly. When I put my head to the machine, I saw two complete sets of the things we were supposed to read stacked on top of each other. I still passed it, but that made it REALLY fucking difficult...