Cocoa -- toggling a BOOL without repeating its name.

Question

If a BOOL has a nice short name, it's easy enough to write:

myBOOL = !myBOOL;

But what if the BOOL has a long name?

objectWithLongishName.memberWithLongishName.submember.myBOOL = !(objectWithLongishName.memberWithLongishName.submember.myBOOL);  

. . . does not look so pretty.

I'm wondering if there is an easy way to toggle the BOOL without entering its name twice?

Answer 1

No there isn't an obvious way in (Objective-)C to do what you describe (without using a preprocessor macro), but see Seva's answer for a possible (though potentially brittle) solution. More importantly, something like objectWithLongishName.memberWithLongishName.submember.myBOOL indicates a Law of Demeter violation; you should be providing submember directly to any code unit that needs to access submember.myBOOL.

Answer 2

Write a method for the submember class that toggles it for you?

- (void) toggleMyBOOL {
  self.myBool = !self.myBool;
}

Then you can do:

[objectWithLongishName.memberWithLongishName.submember toggleMyBOOL];

Answer 3

#define NOT(b) (b) = !(b)

NOT(MyBooleanVariableWithAFreakishlyLongName);

Or, if it's Objective C++:

void NOT(BOOL &b)
{
    b = !b;
}

Answer 4

Here's another:

MyBooleanYaddaYadda ^= YES;

This is kinda brittle - it will break on legacy C code that implies that any nonzero integer evaluates to true. But then again, so will Apple framework code - I encountered cases in Cocoa where a nonzero, non-one int, when passed as a BOOL, would not cause the same effect as passing a YES.

However, it does not rely on the bit pattern of YES - only on NO being 0. Which is pretty much a given, giving the way C interprets integers as logical values. Also, it does not assume the actual datatype of BOOL (which on Cocoa is signed char, by the way).

Answer 5

Use XOR. In C, this is ^.

BOOL x = YES;
x ^= YES; // it's now NO
x ^= YES; // it's now YES
x ^= YES; // it's now NO
x ^= YES; // it's now YES
x ^= YES; // it's now NO
x ^= YES; // it's now YES
...

Edit: someone posted this already, apparently. I guess I should say I've never actually used this in code. :-)

Answer 6

You have a lovely set of answers focused on flipping a YES to a NO or vice-versa, but no answers that touched on what would appear to be an architectural issue in the code.

Well, some answers. I'm blind.

Namely, you have this:

objectWithLongishName.memberWithLongishName.submember.myBOOL =
    !(objectWithLongishName.memberWithLongishName.submember.myBOOL);  

That smells like a potential encapsulation violation. In particular (and assuming this is a model layer), it means that the connectivity of the sub-graph of objects is being overtly exposed -- flattened into, effectively -- the entry point of that path; whatever objectWithLongishName is must now have rather intimate knowledge of the innards of the objects along the rest of the path.

Typically, you don't reach deeply into the model layer along key paths to edit state outside of the Cocoa Bindings layer (and even that is a bit fragile).

Sometimes such long-ish paths do make sense. In such a case, I would leave the über-verbose form you have above as a visual indication that encapsulation is being purposefully shred.