¿Por qué sobrecargar verdadero y falso en lugar de definir el operador bool?

Question

He estado leyendo sobre la sobrecarga de verdadero y falso en C#, y creo que entiendo la diferencia básica entre esto y la definición de un operador bool. El ejemplo que veo alrededor es algo así como:

public static bool operator true(Foo foo) { 
    return (foo.PropA > 0); 
} 
public static bool operator false(Foo foo) { 
    return (foo.PropA <= 0); 
} 

Para mí, esto es lo mismo que decir:

public static implicit operator bool(Foo foo) { 
    return (foo.PropA > 0); 
} 

La diferencia, por lo que yo puedo decir, es que mediante la definición verdadero y falso por separado, puede tener un objeto que es a la vez verdadera y falsa o verdadera ni falsa:

public static bool operator true(Foo foo) { return true; } 
public static bool operator false(Foo foo) { return true; } 
//or 
public static bool operator true(Foo foo) { return false; } 
public static bool operator false(Foo foo) { return false; } 

estoy seguro de que hay una razón esto está permitido, pero simplemente no puede pensar en lo que es. Para mí, si quieres que un objeto se convierta en verdadero o falso, un solo operador de bool tiene más sentido.

¿Alguien puede darme un escenario donde tiene sentido hacerlo de otra manera?

Gracias

Answer 1

Como the docs decir, la sobrecarga true y false está destinado a apoyar (anulables) de bases de datos de tipo (Sí/No, S/N, 0/1, etc.).

Y, por supuesto, puede definirlos de forma incoherente, como con cualquier operador. Es su responsabilidad devolver algo sensato. El compilador no va más allá de requerir ninguno o ambos.

Answer 2

En función del sistema, la verdadera pueden ser cualquier valor que no sea cero. En otros, puede ser cualquier valor positivo.

Otros sistemas no son verdaderamente booleanos, y permiten un tercer estado nulo o nulo para los valores booleanos, por lo que puede sobrecargar verdadero y falso, en vez de sobrecargar un solo operador bool.

Answer 3

He visto personas sobrecargar las sobrecargas true y false para hacer cosas inteligentes como construir expresiones en .NET 2.0, antes de que existiera Linq.

Ayende elaborado una sintaxis como esta para construir criterios de NHibernate consultas, mediante su proyecto NHQG:

return Repository.FindAll(
    (Where.Publisher.Name == name) && 
    (Where.Publisher.City == city)); 

Answer 4

no tenía ni idea existían estos operadores. Esto significa que puede poner en práctica la paradoja de auto-negación:

public class ThisClassIsFalse 
{ 
    public static bool operator true(ThisClassIsFalse statement) 
    { 
     return statement ? false : true; 
    } 

    public static bool operator false(ThisClassIsFalse statement) 
    { 
     return statement ? true : false; 
    } 
} 

Así que ahora sabemos la verdadera solución a esta paradoja clásica ... StackOverflowException.