Trinary Boolean strikes again



  • So, our database tracks operational (things we care about), filtered (what we might care about, but needs review) and deleted (we've looked at and we don't need but the powers-that-be want to keep for 'trending') stuff in our database. The tables are identical except the table(s) name prefixes. There is a drop down in various parts of the GUI which allow you to switch which hunk of the database you are querying. When that drop down is activated, it updates a Boolean, and, in-turn, a string value which is used as a prefix for the SQL FROM clauses to choose the different table 'sets'.

    public void setChangedDatabase(Boolean cd) {
      changedDatabase = cd;
      if (changedDatabase != null) {
        if (changedDatabase.booleanValue()) {
          changedDatabaseString = "Filtered_";
        } else {
          changedDatabaseString = "Deleted_";
        }
      } else {
        changedDatabaseString = "";
      }
    }
    Remeniscent of FILE_NOT_FOUND?


  • Null, True or False.

    Eh, this one isn't gettin to me. It's a trinary boolean, but not terribly WTF-y, IMHO.



  • Looks pretty much like C#'s bool? syntax. But it does seem like a very bad abuse of a boolean since it doesn't seem to really be a boolean (does "Filtered_" mean "changedDatabase" is true? It doesn't sound like a reasonable logic from what I can see).



  •  Hmmm, I see the resemblance, but I think the real WTF is that he should have thrown an exception in the null case? Seems like this would be the best course of action.



  • It appears to be a boolean literal wrapped in a Boolean object and as such a test for null is an acceptable thing to do.


  • FoxDev

    @zelmak said:

    public void setChangedDatabase(Boolean cd) {
    changedDatabase = cd;
    if (changedDatabase != null) {
    if (changedDatabase.booleanValue()) {
    changedDatabaseString = "Filtered_";
    } else {
    changedDatabaseString = "Deleted_";
    }
    } else {
    changedDatabaseString = "";
    }
    }

     

    It's Java - this is not a WTF. In Java, Boolean is a class.


  • But it does seem like a very bad abuse of a boolean since it doesn't seem to really be a boolean (does "Filtered_" mean "changedDatabase" is true? It doesn't sound like a reasonable logic from what I can see).

    The full "logic" (which I agree is unreasonable) is that changedDatabase is null (no, the database didn't change from original) or true (yes, it changed to Filtered) or false (yes, it changed to Deleted). Like FILENOTFOUND, when the metaphor is this non-intuitive, you should use an enum instead.



  • Very well: TRWTF is using null Booleans as part of the normal process flow in order to get tristate values.

    Edit:  Beaten to it again!!  I could have typed faster, but I'm eating a bag of mixed nuts and have keyboard-corrosive salts all over my fingers.



  • @emurphy said:

    But it does seem like a very bad abuse of a boolean since it doesn't seem to really be a boolean (does "Filtered_" mean "changedDatabase" is true? It doesn't sound like a reasonable logic from what I can see).

    The full "logic" (which I agree is unreasonable) is that changedDatabase is null (no, the database didn't change from original) or true (yes, it changed to Filtered) or false (yes, it changed to Deleted). Like FILENOTFOUND, when the metaphor is this non-intuitive, you should use an enum instead.

     

     As I understand it, this was written before Enums existed. SO they'd have to have a static class with static final public int CHANGED, FILTERED, UNCHANGED values in it. As I said earlier, it makes reasonable sense to me



  • @emurphy said:

    But it does seem like a very bad abuse of a boolean since it doesn't seem to really be a boolean (does "Filtered_" mean "changedDatabase" is true? It doesn't sound like a reasonable logic from what I can see).

    The full "logic" (which I agree is unreasonable) is that changedDatabase is null (no, the database didn't change from original) or true (yes, it changed to Filtered) or false (yes, it changed to Deleted). Like FILENOTFOUND, when the metaphor is this non-intuitive, you should use an enum instead.

    An enum of wtf values is still a wtf!



  • @zelmak said:

    So, our database tracks operational (things we care about), filtered (what we might care about, but needs review) and deleted (we've looked at and we don't need but the powers-that-be want to keep for 'trending') stuff in our database. The tables are identical except the table(s) name prefixes. There is a drop down in various parts of the GUI which allow you to switch which hunk of the database you are querying. When that drop down is activated, it updates a Boolean, and, in-turn, a string value which is used as a prefix for the SQL FROM clauses to choose the different table 'sets'.

    public void setChangedDatabase(Boolean cd) {
    changedDatabase = cd;
    if (changedDatabase != null) {
    if (changedDatabase.booleanValue()) {
    changedDatabaseString = "Filtered_";
    } else {
    changedDatabaseString = "Deleted_";
    }
    } else {
    changedDatabaseString = "";
    }
    }
    Remeniscent of FILE_NOT_FOUND?

    My guess on what happened here is that there used to be only one database. Then, requirements changed, and they needed two databases (operational or deleted; boolean, right?). Finally, a third one came along, and they had to hack support for it in.

    TRWTF is that the world continues to change after software is written.



  • In the computing world in which I operate, "null" is a forbidden concept.  Instead you have constructs that more accurately represent what's going on: each variable has one flag and one conceptual enumeration associated with it. The flag is "this variable should be considered in computations" versus "this variable should not be considered in computations." The conceptual enumeration, which is only useful if the value should be considered in computations in the first place, is "the value is valid, the valid is invalid, the validity of the value has not yet been established."

    Personally, I think the concept of a "null" value is dubious, because a value cannot be "null"; the "null"-ness of a value is metadata and is outside the scope of the actual value itself.  For instance, if someone says "what is your middle name" and you don't have one, you answer "I don't have a middle name." The value of your middle name is not "null", you don't have an empty placeholder; the entire concept of a middle name just doesn't even apply to you.

    Yes, perhaps this is a semantic or philosophical pedantry. And I even fully agree that the concept of "null" is much simpler to deal with as a form of syntactic sugar than specifically checking for "this field actually has meaning for this record."  So actually, in retrospect, I don't know why I've been rambling on here.  I guess it's been one of those weeks.



  • @too_many_usernames said:

    In the computing world in which I operate, "null" is a forbidden concept. 
     

    Which is? I'm curious now.

    @too_many_usernames said:

    if someone says "what is your middle name" and you don't have one, you answer "I don't have a middle name." The value of your middle name is not "null", you don't have an empty placeholder; the entire concept of a middle name just doesn't even apply to you.

    You realize the difference between "uninitialized" (null) and "initialized but empty"? ("")



  •  I was laughin so hard when I found this while doing research for a client. ^_^


Log in to reply