Cacao - alternar un BOOL sin repetir su nombre

Question

Si un BOOL tiene un bonito nombre corto, que es bastante fácil de escribir:

myBOOL = !myBOOL; 

Pero ¿y si la BOOL tiene un nombre largo?

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

. . . no se ve tan bonito

Me pregunto si hay una manera fácil de alternar el BOOL sin ingresar su nombre dos veces?

Answer 1

Aquí hay otro:

MyBooleanYaddaYadda ^= YES; 

Esto es algo frágil: se romperá en el código C heredado que implica que cualquier entero distinto de cero se evalúa como verdadero. Pero, de nuevo, también lo hará el código del marco de Apple: encontré casos en Cocoa donde un int no distinto de cero, cuando pasaba como BOOL, no causaba el mismo efecto que pasar un SÍ.

Sin embargo, no se basa en el patrón de bits de SÍ, solo en NO es 0. Lo cual es casi un hecho, considerando la forma en que C interpreta los enteros como valores lógicos. Además, no asume el tipo de datos real de BOOL (que en Cocoa es signed char, por cierto).

El patrón de bits de YES en Cocoa es 1. Pero esa no es una convención universal. En algunas plataformas sin tipo de datos booleanos incorporados, la constante entera que sirve como TRUE lógico es -1 - todos los bits. Eso es 0xFFFFFFFF si se interpreta como sin signo. Esta codificación tiene una vaga ventaja de que bitwize NOT (el operador ~ en C) es equivalente a NOT lógico (el operador! En C). Es decir, ~ 0xFFFFFFFF es 0, i. mi. ~ TRUE es FALSO. No funciona de esa manera si TRUE se define como 1.

Answer 2

No hay una manera obvia en (Objective-) C de hacer lo que usted describe (sin usar un macro de preprocesador), pero vea la respuesta de Seva para una posible solución (aunque potencialmente frágil). Más importante aún, algo como objectWithLongishName.memberWithLongishName.submember.myBOOL indica una violación Law of Demeter; Debería proporcionar submember directamente a cualquier unidad de código que necesite acceder al submember.myBOOL.

Answer 3

Escriba un método para la clase submember que lo cambia por usted?

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

A continuación, puede hacer:

[objectWithLongishName.memberWithLongishName.submember toggleMyBOOL]; 

Answer 4

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

NOT(MyBooleanVariableWithAFreakishlyLongName); 

O, si se trata de Objective C++:

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

Answer 5

Use XOR. En C, esto es ^.

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

Editar: Alguien ha publicado esto, aparentemente. Creo que debería decir que nunca he usado esto en el código. :-)

Answer 6

Tiene un conjunto precioso de respuestas centradas en cambiar un SÍ a un NO o viceversa, pero no responde que tocó lo que podría parecer un problema arquitectónico en el código.

Bueno, algunas respuestas. Estoy ciego.

Es decir, que tienen la siguiente:

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

que huele a una posible violación de encapsulación. En particular (y suponiendo que se trata de una capa de modelo), significa que la conectividad del subgrupo de objetos se expone abiertamente, se aplana, de manera efectiva, el punto de entrada de esa ruta; cualquiera que sea objectWithLongishName, ahora debe tener un conocimiento más bien íntimo de las entrañas de los objetos a lo largo del resto del camino.

Normalmente, no se profundiza en la capa de modelo a lo largo de las rutas clave para editar el estado fuera de la capa de enlaces de cacao (e incluso eso es un poco frágil).

A veces, estos caminos largos tienen sentido. En tal caso, dejaría la forma über-verbose que tiene arriba como una indicación visual de que la encapsulación se destruye a propósito.