Random Questions

Ikatono · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

Why not just do this?


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

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

Pegu · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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) · November 2012


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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

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 · November 2012

SNAP

MATATAT · November 2012

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 · November 2012

...and lackofcheese wins the thread.

SNAP

MATATAT · November 2012

I can dig it.

ninjarabbi · November 2012

Any good ideas for a homemade recoil pad?

Jack Draigo · November 2012

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 · November 2012

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

Sail · November 2012

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 · November 2012

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

Looks decent enough.

Victor Frost · November 2012

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

open_sketchbook · November 2012

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 · November 2012

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...

Howdy, Stranger!

Categories

Random Questions

Comments