La classe booléenne de Java - pourquoi pas une énumération?

Il me semble que la classe booléenne est un candidat idéal pour être implémenté en tant qu'énumération.

En regardant le code source, la plupart de la classe est constituée de méthodes statiques qui pourraient être déplacées inchangées vers une énumération, le reste devenant beaucoup plus simple comme une énumération. Comparer l'original (commentaires et méthodes statiques supprimés):

public final class Boolean implements java.io.Serializable,
                                      Comparable<Boolean>
{
   public static final Boolean TRUE = new Boolean(true);
  public static final Boolean FALSE = new Boolean(false);
   private final boolean value;
   public Boolean(boolean value) {
       this.value = value;
   }
   public Boolean(String s) {
       this(toBoolean(s));
   }
   public boolean booleanValue() {
       return value;
   }
   public String toString() {
       return value ? "true" : "false";
   }
   public int hashCode() {
       return value ? 1231 : 1237;
   }
   public boolean equals(Object obj) {
       if (obj instanceof Boolean) {
           return value == ((Boolean)obj).booleanValue();
       }
       return false;
   }
   public int compareTo(Boolean b) {
       return compare(this.value, b.value);
   }
}

avec une version enum:

public enum Boolean implements Comparable<Boolean>
{
   FALSE(false), TRUE(true);
   private Boolean(boolean value) {
       this.value = value;
   }
   private final boolean value;
   public boolean booleanValue() {
       return value;
   }

   public String toString() {
       return value ? "true" : "false";
   }
}

Y a-t-il une raison pour laquelle Boolean ne peut pas devenir un enum?

S'il s'agit du code Sun pour remplacer la méthode equals (), il manque une vérification très fondamentale de la comparaison des références des deux objets avant de comparer leurs valeurs. Voici comment je pense que la méthode equals () devrait être:

   public boolean equals(Object obj) {

       if (this == obj) {
          return true;
       }

       if (obj instanceof Boolean) {
           return value == ((Boolean)obj).booleanValue();
       }
       return false;
   }

Eh bien, je suppose que je pourrais commencer par faire valoir que les énumérations Java n'ont pas été ajoutées au langage de programmation Java avant le JDK 1.5. et par conséquent, cette solution n'était même pas une alternative au début lorsque la classe booléenne a été définie.

Cela étant dit, Java a la réputation de conserver la compatibilité descendante entre les versions et donc, même si nous considérons aujourd'hui votre solution comme une bonne alternative, nous ne pouvons pas le faire sans casser des milliers de lignes de code en utilisant déjà l'ancien booléen. classe.

Il y a certaines choses qui ne fonctionnent pas, et ne fonctionnent pas de manière assez surprenante lorsque vous les comparez aux fonctionnalités précédentes du booléen Java.

Nous allons ignorer la boxe car cela a été ajouté avec 1.5. En théorie, si Sun l'avait voulu, ils auraient pu faire en sorte que le enum Booleancomportement se fasse exactement comme celui de la boxe class Boolean.

Pourtant, il existe d'autres façons surprenantes (pour le codeur) que cela se briserait soudainement par rapport à la fonctionnalité de la classe précédente.

Le problème valueOf (String)

Un exemple simple de ceci est:

public class BooleanStuff {
    public static void main(String args[]) {
        Boolean foo = Boolean.valueOf("TRUE");
        System.out.println(foo);
        foo = Boolean.valueOf("TrUe");
        System.out.println(foo);
        foo = Boolean.valueOf("yes");  // this is actually false
        System.out.println(foo);

        // Above this line is perfectly acceptable Java 1.3
        // Below this line takes Java 1.5 or later

        MyBoolean bar;
        bar = MyBoolean.valueOf("FALSE");
        System.out.println(bar);
        bar = MyBoolean.valueOf("FaLsE");
        System.out.println(bar);
    }

    enum MyBoolean implements Comparable<MyBoolean> {
        FALSE(false), TRUE(true);
        private MyBoolean(boolean value) { this.value = value; }
        private final boolean value;
        public boolean booleanValue() { return value; }
        public String toString() { return value ? "true" : "false"; }
    }
}

L'exécution de ce code donne:

vrai
vrai
faux
faux
Exception dans le thread "main" java.lang.IllegalArgumentException: aucune constante enum BooleanStuff.MyBoolean.FaLsE
    à java.lang.Enum.valueOf (Enum.java:236)
    à BooleanStuff $ MyBoolean.valueOf (BooleanStuff.java:17)
    à BooleanStuff.main (BooleanStuff.java:13)

Le problème ici est que je ne peux pas passer à travers tout ce qui est pas TRUEou FALSEà valueOf(String).

C'est ok ... nous allons simplement le remplacer par notre propre méthode ...

    public static MyBoolean valueOf(String arg) {
        return arg.equalsIgnoreCase("true") ? TRUE : FALSE;
    }

Mais ... il y a un problème ici. Vous ne pouvez pas remplacer une méthode statique .

Et donc, tout le code qui circule trueou tout Trueautre cas mélangé sera erroné - et de manière assez spectaculaire avec une exception d'exécution.

Un peu plus de plaisir avec valueOf

Il y a quelques autres bits qui ne fonctionnent pas trop bien:

public static void main(String args[]) {
    Boolean foo = Boolean.valueOf(Boolean.valueOf("TRUE"));
    System.out.println(foo);

    MyBoolean bar = MyBoolean.valueOf(MyBoolean.valueOf("FALSE"));
    System.out.println(bar);
}

Pour foo, je reçois juste un avertissement concernant la mise en boîte d'une valeur déjà en boîte. Cependant, le code pour bar est une erreur de syntaxe:

Erreur: (7, 24) java: aucune méthode appropriée trouvée pour valueOf (BooleanStuff.MyBoolean)
    la méthode BooleanStuff.MyBoolean.valueOf (java.lang.String) n'est pas applicable
      (l'argument réel BooleanStuff.MyBoolean ne peut pas être converti en java.lang.String par conversion d'invocation de méthode)
    la méthode java.lang.Enum.valueOf (java.lang.Class, java.lang.String) n'est pas applicable
      (ne peut pas instancier d'arguments car les listes d'arguments réelles et formelles diffèrent en longueur)

Si nous contraignons cette erreur de syntaxe dans un Stringtype:

public static void main(String args[]) {
    Boolean foo = Boolean.valueOf(Boolean.valueOf("TRUE"));
    System.out.println(foo);

    MyBoolean bar = MyBoolean.valueOf(MyBoolean.valueOf("FALSE").toString());
    System.out.println(bar);
}

Nous récupérons notre erreur d'exécution:

vrai
Exception dans le thread "main" java.lang.IllegalArgumentException: aucune constante enum BooleanStuff.MyBoolean.false
    à java.lang.Enum.valueOf (Enum.java:236)
    à BooleanStuff $ MyBoolean.valueOf (BooleanStuff.java:11)
    à BooleanStuff.main (BooleanStuff.java:7)

Pourquoi quelqu'un écrirait ça? Je ne sais pas ... mais son code qui fonctionnait et ne fonctionnerait plus.

Ne vous méprenez pas, j'aime vraiment l'idée d'une seule copie d'un objet immuable donné. L'énumération résout ce problème. J'ai personnellement rencontré du code fournisseur contenant des bogues provenant du code fournisseur qui ressemblait à ceci:

if(boolValue == new Boolean("true")) { ... }

cela n'a jamais fonctionné _{^{(non, je ne l'ai pas corrigé car l'état incorrect a été corrigé ailleurs, et la correction de cela a cassé cela de manière étrange que je n'ai vraiment pas eu le temps de déboguer)}} . S'il s'agissait d'une énumération, ce code aurait plutôt fonctionné.

Cependant, les nécessités de la syntaxe autour de l'énumération (sensible à la casse - creuser dans l' énumConstantDirectory derrière valueOf, les erreurs d'exécution qui doivent fonctionner de cette façon pour les autres énumérations) et le fonctionnement des méthodes statiques provoquent un certain nombre de choses à casser qui l'empêchent de étant une baisse en remplacement d'un booléen.

Très probablement parce que le booleantype primitif n'est pas un Enum, et les versions en boîte des types primitifs se comportent presque de manière identique à leur version non en boîte. Par exemple

Integer x = 5;
Integer y = 7;
Integer z = x + y;

(La performance n'est peut-être pas la même, mais c'est un sujet différent.)

Ce serait un peu étrange si vous pouviez écrire:

Boolean b = Boolean.TRUE;
switch (b) {
case Boolean.TRUE:
    // do things
    break;
case Boolean.FALSE:
    // do things
    break;
}

mais non:

boolean b = true;
switch(b) {
case true:
    // do things
    break;
case false:
    // do things
    break;
}  

En plus de valueOfproblème (qui est un problème au niveau Java, cela pourrait bien fonctionner au niveau JVM), c'est parce qu'il Booleana un constructeur public. C'était une mauvaise idée, actuellement déconseillée, mais c'est celle qui est là pour rester.

La raison en est que "bool" faisait partie du langage Java bien avant "enum". Pendant de nombreuses années, "bool" était très souhaitable, tandis que "enum" n'était pas disponible. Ce n'est que maintenant que vous pouvez dire "si l'énumération était disponible depuis le début, alors nous aurions pu implémenter bool comme une énumération au lieu d'un type séparé".

Dans Swift, qui aurait pu exprimer "bool" comme une énumération, il existe trois structures nommées "Bool", "DarwinBoolean" et "ObjCBool" implémentant le protocole "ExpressibleByBooleanLiteral". (DarwinBoolean est compatible avec un booléen C ou C ++, ObjCBool ​​est compatible avec un BOOL Objective-C). "true" et "false" sont des valeurs spéciales reconnues par le compilateur et ne peuvent être utilisées que pour initialiser des objets prenant en charge le protocole "ExpressibleByBooleanLiteral". Bool a une variable interne "_value" contenant un entier d'un bit.

Bool ne fait donc pas partie du langage Swift, mais de la bibliothèque standard. true et false font partie du langage, tout comme le protocole ExpressibleByBooleanLiteral.