New: Support for {True;False;FileNotFound}



  • Hi...

     

    I was just reading whats new in Refactor 2.1 and i came around this snippet in the "whats new"-list:

    (Link: http://community.devexpress.com/blogs/ctodx/archive/2007/01/11/657.aspx )

    ...

    Boolean to Enum converts a Boolean type to an enumeration, updating client code if necessary. This is for those occasions where you have an existing method returning a Boolean, but suddenly realize that there is another result you want to return (for fans of The Daily WTF, this means you can now convert a Boolean result into an enumeration with True, False, and FileNotFound).

    ...

     

    Now there is a way to automate creating this type of WTF ;) 

     



  • Hm, interesting. Actually there are a few occasion where that might come in handy. However, there will be a lot of people who will play with this new toy excessively. Can't wait for the WTFs caused by those.

    A WTF I can think of: TRUE, FALSE, EXCEPTION :) 

    edit: on second thought, I think it's utter nonsense. You cannot treat booleans like enums, can you? 



  • Niiiiiiiiiiiiiiiiiiiiiiiice!

    enum Boolean {True, False, SortOfTrue, SortOfFalse, NotSure, Probably, Possibly, Sometimes, Maybe, FILE_NOT_FOUND}



  • Ha! I scoff at your binary logic!



  • From the page:

    "Boolean to Enum converts a Boolean type to an enumeration, updating client code if necessary. This is for those occasions where you have an existing method returning a Boolean, but suddenly realize that there is another result you want to return (for fans of The Daily WTF, this means you can now convert a Boolean result into an enumeration with True, False, and FileNotFound)."

     
    So, they KNOW that True/False/FileNotFound is a dumb thing, because it crops up here so often. But they add that feature anyway? Okay, so I can see some uses for the feature (turning a function like IsThisAppleRed() (returning true/false) to the more informative GetAppleColour() (returning RED/GREEN)), but they're advertising it as a tool for deliberate WTFery. How bizarre...

     



  • It kind of makes sense, but still it breaks the attitude that a boolean is nothing more then a bi-state enum with two standard defined values of true and false.

    Basically an enumerator is a list of items which are all mutually exclusive to each other.  A list is two or more unique items. 

    Following this logic, a boolean is an enum, but an enum is not a boolean in the same way that a square is a rectangle but a rectangle is not a square.

    If you ever need a third value you should no longer use a boolean or even attempt to.  Perfect examples follow:

    Some people like trying to save gender as "Male?"  This gives you a true false, with false implying female.  Problem is this is engineered wrong, gender is not male or otherwise, it is male or female (barring the other unusual chromosonal combinatations).  Since the choices are Male and Female, it is not boolean since gender is neither true or false.  Alternatively an Alive flag can be a boolean as you very specifically know if they are alive or dead and can represented as true or false.

    This tool allows poorly engeneered applications to abuse the idea of a boolean, fine for a mid-process refactoring but bad in the long run.



  • @KattMan said:

    It kind of makes sense, but still it breaks the attitude that a boolean is nothing more then a bi-state enum [ ...snip... ]

    [ ...snip... ] a boolean is an enum, but an enum is not a boolean [ ...snip... ]

    If you ever need a third value you should no longer use a boolean or even attempt to.  [ ...snip... ]

    This tool allows poorly engeneered applications to abuse the idea of a boolean, [ ...snip... ]

     

      You totally missed the point.  It doesn't try to squeeze three values into a bool at all.  It converts bools to enums, therefore making it legitimate to add a third value.

     

     



  • @ElectroDruid said:

    So, they KNOW that
    True/False/FileNotFound is a dumb thing, because it crops up here so
    often. But they add that feature anyway? Okay, so I can see some uses
    for the feature (turning a function like IsThisAppleRed() (returning
    true/false) to the more informative GetAppleColour() (returning
    RED/GREEN)), but they're advertising it as a tool for deliberate
    WTFery. How bizarre...

     

      I think
    you forgot to engage your sense of humour before reading the
    excerpt.  It is /of course/ intended for the sane applications
    such as your IsRed -> R/G/B idea above.  They just threw in a
    jokey example in the explanation.

     



  • @DaveK said:

    @KattMan said:

    It kind of makes sense, but still it breaks the attitude that a boolean is nothing more then a bi-state enum [ ...snip... ]

    [ ...snip... ] a boolean is an enum, but an enum is not a boolean [ ...snip... ]

    If you ever need a third value you should no longer use a boolean or even attempt to.  [ ...snip... ]

    This tool allows poorly engeneered applications to abuse the idea of a boolean, [ ...snip... ]

      You totally missed the point.  It doesn't try to squeeze three values into a bool at all.  It converts bools to enums, therefore making it legitimate to add a third value.

    I don't think he missed the point. In fact he's right on it. Instead of extending a bool to become an enum you should rather consider defining a whole new enumeration. It does not make sense to extend true/false. Imagine you have such an enum X that has been derived from a bool. What is !X then? Such conversion entails a loss of the semantics of a Bool. If you need more than two values then use another data type like an integer to encode the result (or even better and simpler a new enum).

    @KattMan said:

    Some people like trying to save gender as "Male?"  This gives you a true false, with false implying female.  Problem is this is engineered wrong, gender is not male or otherwise, it is male or female (barring the other unusual chromosonal combinatations).  Since the choices are Male and Female, it is not boolean since gender is neither true or false.  Alternatively an Alive flag can be a boolean as you very specifically know if they are alive or dead and can represented as true or false.

    You pointed out the difference between the semantics and the internal representation of a gender. I agree with most of what you said. However, the male/female problem can be paraphrased as you already mentioned. Instead of a value named GENDER being TRUE or FALSE you could rename it to IS_MALE or IS_FEMALE. In that case the use of a boolean is "semantically" correct IMHO. Of course it favours one gender but noone said that code needs to be political correct. :)



  • @DaveK said:

     

     
    You totally missed the point.  It doesn't try to squeeze three
    values into a bool at all.  It converts bools to enums, therefore
    making it legitimate to add a third value.

     

     

     

    Damned ! I thought it was the first step to fuzzy logic and this marvelous world where a bit could be something between 0 and 1 :o)
     



  • @snoofle said:

    enum Boolean {True, False, SortOfTrue, SortOfFalse, NotSure, Probably, Possibly, Sometimes, Maybe, FILE_NOT_FOUND}

     Don't forget:

    • Signs point to yes.
    • Yes.
    • Most likely.
    • Without a doubt.
    • Yes - definitely.
     
    • As I see it, yes.
    • You may rely on it.
    • Outlook good.
    • It is certain.
    • It is decidedly so.
     
    • Reply hazy, try again.
    • Better not tell you now.
    • Ask again later.
    • Concentrate and ask again.
    • Cannot predict now.
     
    • My sources say no.
    • Very doubtful.
    • My reply is no.
    • Outlook not so good.
    • Don't count on it.

     



  • I, for one, welcome my new n logic masters with open arms.

    I plan to start rewriting my code to support True, False, FileNotFound, Brillant immediately.



  • @Phalphalak said:

    @KattMan said:

    Some people like trying to save gender as "Male?"  This gives you a true false, with false implying female.  Problem is this is engineered wrong, gender is not male or otherwise, it is male or female (barring the other unusual chromosonal combinatations).  Since the choices are Male and Female, it is not boolean since gender is neither true or false.  Alternatively an Alive flag can be a boolean as you very specifically know if they are alive or dead and can represented as true or false.

    You pointed out the difference between the semantics and the internal representation of a gender. I agree with most of what you said. However, the male/female problem can be paraphrased as you already mentioned. Instead of a value named GENDER being TRUE or FALSE you could rename it to IS_MALE or IS_FEMALE. In that case the use of a boolean is "semantically" correct IMHO. Of course it favours one gender but noone said that code needs to be political correct. :)

     Actually I don't think I missed it at all, but I did fail to explain it further.  If you have a field called IS_Male, you could use True/False, but this means that False implies female, when in truth it does not, It implies the fact they did not say male.  Think of cases where people simply refuse to enter thier gender, with a IS_MALE flag you imply these people are female.  In applications that have this field as optional this is not good.  If the gender is required (let's say at a health clinic) this might work, but rarely is this the case.  This is the inherent difference between absolute values and those values that can be just a bit fuzzy and the rules can be bent depending on your situation.

    In the alive/dead scenario it is safe to assume that the person is alive until they are dead, or even that an address is valid until it is not.  In these cases the assumption is safe, keep sending someone's subsscription to thier address on file until you get a returned package, then you mark it as invalid so you don't send anything out anymore.  At this point your customer service can make the contact, get the new address and assume it is correct until the return happens again.  This is a true false scenario, not a did he give it to us or not and what is our assumption if not scenario.

    But as I said before, this product gives a good method of casting poorly decided on booleans to enums (like a gender flag) for a mid-process refactoring stage.  Anything that can assist in correcting issues quickly should be considered, but do not use this as your final solution.



  • @ShadowWolf said:

    I, for one, welcome my new n logic masters with open arms.

    I plan to start rewriting my code to support True, False, FileNotFound, Brillant immediately.

    Then you already have the tools at your disposal, they are called enumerators.



  • I can see how this is  a good idea in principle. Still, I wonder, what will the converter do with, let's say x = !x?

    I mean, sure, on first glance a boolean could be considered a two element enum, but isn't the big difference that the values have special meanings and that there are logical operators to manipulate them?



  • This is going to be perfect for my new fuzzy logic system.



    public enum bool {0.00000000, 0.00000001, 0.00000002, 0.00000003, 0.00000004, 0.00000005, 0.00000006, 0.00000007, 0.00000008...



  • @KattMan said:

    If you ever need a third value you should no longer use a boolean or even attempt to.  Perfect examples follow:

    Some people like trying to save gender as "Male?"  This gives you a true false, with false implying female.  Problem is this is engineered wrong, gender is not male or otherwise, it is male or female (barring the other unusual chromosonal combinatations).  Since the choices are Male and Female, it is not boolean since gender is neither true or false.  Alternatively an Alive flag can be a boolean as you very specifically know if they are alive or dead and can represented as true or false.

    This tool allows poorly engeneered applications to abuse the idea of a boolean, fine for a mid-process refactoring but bad in the long run.

    Except that using male / female as [i]gender[/i] is confusing because it can also be part of the biological sex enum { freemartin, hermaphrodite, male, female }. Hell, with this you could add extra ones for eunuch, post-hysterectomy, chemically castrated etc..



  • @MrBester said:

    @KattMan said:
    If you ever need a third value you should no longer use a boolean or even attempt to.  Perfect examples follow:

    Some people like trying to save gender as "Male?"  This gives you a true false, with false implying female.  Problem is this is engineered wrong, gender is not male or otherwise, it is male or female (barring the other unusual chromosonal combinatations).  Since the choices are Male and Female, it is not boolean since gender is neither true or false.  Alternatively an Alive flag can be a boolean as you very specifically know if they are alive or dead and can represented as true or false.

    This tool allows poorly engeneered applications to abuse the idea of a boolean, fine for a mid-process refactoring but bad in the long run.

    Except that using male / female as [i]gender[/i] is confusing because it can also be part of the biological sex enum { freemartin, hermaphrodite, male, female }. Hell, with this you could add extra ones for eunuch, post-hysterectomy, chemically castrated etc..

    And you are supporting my statements.  For brevities sake I limited this to two with the statement "(barring the other unusual chromosonal combinatations)".  The statement basically becomes "What is your Gender?" The answer is neither true or false but rather Male or Female, hence it is not a boolean, because you can always add the third "non-disclosed".

    There are, afterall, 5 chromosonal sexes in the human race, most are familiar with the XY and XX sexes being male and female. There is also XYY, XXY and XXX, all of which appear to be female in gender but are infertile.  They are rare and we will see them as female.  The other mutations you suggest still fall into these chromosonal catagories so a gender enum could be limited to 5 items, still not a boolean.  Additionally, there is no YYY combination because there is always a female addition from the mother.



  • @wgh said:

    @snoofle said:

    enum Boolean {True, False, SortOfTrue, SortOfFalse, NotSure, Probably, Possibly, Sometimes, Maybe, FILE_NOT_FOUND}

     Don't forget:

    • Signs point to yes.
    • Yes.
    • Most likely.
    • Without a doubt.
    • Yes - definitely.
     
    • As I see it, yes.
    • You may rely on it.
    • Outlook good.
    • It is certain.
    • It is decidedly so.
     
    • Reply hazy, try again.
    • Better not tell you now.
    • Ask again later.
    • Concentrate and ask again.
    • Cannot predict now.
     
    • My sources say no.
    • Very doubtful.
    • My reply is no.
    • Outlook not so good.
    • Don't count on it.

    For those that missed the full enumeration the first time it went around:

    NULL = ?
    0 = Zero
    1 = Yes
    2 = No
    3 = Grayed (dimmed)
    4 = NULL
    5 = NUL
    6 = There is NO Value #6
    7 = Not Specified
    8 = Not Applicable
    9 = Default
    10 = Denial
    11 = De Mississippi
    12 = Divide by Zero
    13 = Blank
    14 = Empty
    15 = Nothing
    16 = Nil
    17 = Zip
    18 = Unassigned
    19 = Undefined
    20 = Indeterminate
    21 = Unknown
    22 = Unknowable
    23 = Beyond human comprehension
    24 = Maybe
    25 = Partially
    26 = Sometimes
    27 = Yes and No
    28 = Says “no” but means “yes”
    29 = Quantum mechanical
    30 = That’s what you say
    31 = Missing
    32 = Lost
    33 = File not found
    34 = No Carrier
    35 = I forgot
    36 = Didn't get the email
    37 = The dog ate it
    38 = Invalid value entered
    39 = Unrecognized value entered
    40 = Blatantly absurd value entered
    41 = User had head up his/her ass
    42 = The Answer
    43 = It’s secret
    44 = Reply hazy, try again
    45 = Non-value
    46 = Imaginary value
    47 = Drug-induced hallucination
    48 = It’s a value, Captain, but not as we know it
    49 = This is not the value you are looking for
    50 = The truth? You can’t handle the truth!
    51 = Value corrupted
    52 = Value corrupted absolutely
    53 = Untrustworthy value
    54 = Downright evil value
    55 = Worthless value
    56 = Invaluable value
    57 = Family value
    58 = This isn’t really a value
    59 = This isn’t really a field
    60 = This is not my beautiful house
    61 = This is not my beautiful wife
    62 = Error 62
    63 = Error 63
    64 = Etc.
    -1 = Not otherwise specified

    --Rank



  • @KattMan said:

    @MrBester said:
    @KattMan said:
    If you ever need a third value you should no longer use a boolean or even attempt to.  Perfect examples follow:

    Some people like trying to save gender as "Male?"  This gives you a true false, with false implying female.  Problem is this is engineered wrong, gender is not male or otherwise, it is male or female (barring the other unusual chromosonal combinatations).  Since the choices are Male and Female, it is not boolean since gender is neither true or false.  Alternatively an Alive flag can be a boolean as you very specifically know if they are alive or dead and can represented as true or false.

    This tool allows poorly engeneered applications to abuse the idea of a boolean, fine for a mid-process refactoring but bad in the long run.

    Except that using male / female as [i]gender[/i] is confusing because it can also be part of the biological sex enum { freemartin, hermaphrodite, male, female }. Hell, with this you could add extra ones for eunuch, post-hysterectomy, chemically castrated etc..

    And you are supporting my statements.  For brevities sake I limited this to two with the statement "(barring the other unusual chromosonal combinatations)".  The statement basically becomes "What is your Gender?" The answer is neither true or false but rather Male or Female, hence it is not a boolean, because you can always add the third "non-disclosed".

    There are, afterall, 5 chromosonal sexes in the human race, most are familiar with the XY and XX sexes being male and female. There is also XYY, XXY and XXX, all of which appear to be female in gender but are infertile.  They are rare and we will see them as female.  The other mutations you suggest still fall into these chromosonal catagories so a gender enum could be limited to 5 items, still not a boolean.  Additionally, there is no YYY combination because there is always a female addition from the mother.

     

     

    HOWEVER! Sometimes when asking for gender you are wanting to know if you should put Mr. or Ms. on the top of the letter you send them.  In such a case it makes more since to ask "Are you a man?" or "Are you a woman?" because that way you will get salutation that they desire.  Some transvestites might consider themselves men and some might consider themselves women.  



  • @Rank Amateur said:

    For those that missed the full enumeration the first time it went around: ...

    You'd win, except that you forgot to account for double negatives. ("Well, it's definitely not false...")

    Or perhaps this is how ! works for an enumeration! 



  • @tster said:

    @KattMan said:

    And you are supporting my statements.  For brevities sake I limited this to two with the statement "(barring the other unusual chromosonal combinatations)".  The statement basically becomes "What is your Gender?" The answer is neither true or false but rather Male or Female, hence it is not a boolean, because you can always add the third "non-disclosed".

    There are, afterall, 5 chromosonal sexes in the human race, most are familiar with the XY and XX sexes being male and female. There is also XYY, XXY and XXX, all of which appear to be female in gender but are infertile.  They are rare and we will see them as female.  The other mutations you suggest still fall into these chromosonal catagories so a gender enum could be limited to 5 items, still not a boolean.  Additionally, there is no YYY combination because there is always a female addition from the mother.

    HOWEVER! Sometimes when asking for gender you are wanting to know if you should put Mr. or Ms. on the top of the letter you send them.  In such a case it makes more since to ask "Are you a man?" or "Are you a woman?" because that way you will get salutation that they desire.  Some transvestites might consider themselves men and some might consider themselves women.  

     

    I would say that in most applications you couldn't care less about any classification beyond male/female. You can argue the ethics of that all you want. If your goal is to merely store the information male/female, it isn't all that weird of a step to use true/false. The error you are making is in thinking true/false still means true/false. You basically changed the semantics to mean something else. Now I would agree that in modern high level languages this is poor programming, since you want to program for clarity. However, in lower level languages it becomes perfectly acceptable. In fact, in C I would argue that designating a true/false value to a bit is misleading, because what you really ask with 'boolean' operators is 'is it zero or not?' This gives false alot more values than true. Of course, if you're programming in C, you should either be put out to pasture, or you're a pretty good programmer who has to optimalize for efficiency (either bits or speed) in which case creative use of data structures becomes an art not a liability.



  • @KattMan said:

    @ShadowWolf said:

    I, for one, welcome my new n logic masters with open arms.

    I plan to start rewriting my code to support True, False, FileNotFound, Brillant immediately.

    Then you already have the tools at your disposal, they are called enumerators.

    Sarcasm lost on too serious of a reader?



  • @Phalphalak said:

    Hm, interesting. Actually there are a few occasion where that might come in handy. However, there will be a lot of people who will play with this new toy excessively. Can't wait for the WTFs caused by those.

    A WTF I can think of: TRUE, FALSE, EXCEPTION :)

    This is not far from truth. For example, a routine that communicates with another system (by sending messages through some network protocol) returns, by original design, true for success or false for failure.

    Unfortunately, as it turns out, there is more than one kind of failure - it makes a difference if the other system explicitely refuses the message or if it is simply unreachable. In the first case, the message is marked as "invalid" (or whatever), in the second case, we have to retry later.



  • @tster said:

    HOWEVER! Sometimes when asking for gender you are wanting to know if you should put Mr. or Ms. on the top of the letter you send them.  In such a case it makes more since to ask "Are you a man?" or "Are you a woman?" because that way you will get salutation that they desire.  Some transvestites might consider themselves men and some might consider themselves women.  

    And some I know go beyond Ms and say what they would really like is for you to use no salutation at all.  I think the idea is that for the vast majority of things your sex is unimportant, so why insist on it being specified every time your name is written?



  • @ShadowWolf said:

    @KattMan said:
    @ShadowWolf said:

    I, for one, welcome my new n logic masters with open arms.

    I plan to start rewriting my code to support True, False, FileNotFound, Brillant immediately.

    Then you already have the tools at your disposal, they are called enumerators.

    Sarcasm lost on too serious of a reader?

    Perhaps I should have put the sarcasm tag around it.  Or were you calling your self the reader? 



  • @MET said:

    @tster said:

    HOWEVER! Sometimes when asking for gender you are wanting to know if you should put Mr. or Ms. on the top of the letter you send them.  In such a case it makes more since to ask "Are you a man?" or "Are you a woman?" because that way you will get salutation that they desire.  Some transvestites might consider themselves men and some might consider themselves women.  

    And some I know go beyond Ms and say what they would really like is for you to use no salutation at all.  I think the idea is that for the vast majority of things your sex is unimportant, so why insist on it being specified every time your name is written?

    And gender should not be used for the salutation either. For men this isn't an issue, but call a married woman Miss or an unmarried woman Mrs. and you may have a problem.  Salutation should be yet another enumerator.  Back to gender though, what happens when you have a "not determined" because they ether did not provide it or they prefer not to be counting in some gender specific survey?

     

    Basically, I stand on this, if a question and be neutrally asked to give a true/false or yes/no response, then it can be a boolean, other wise it should be an enumerator.  The rules can be bent slightly to accommodate.  Gender is Not Yes/No but generally is Male/Female/Unknown.  Is the address valid is Yes/No, there could be a maybe, but this is where you bend it slightly, does the maybe affect processing?  You can assume it is valid until you find out otherwise then mark it invalid or rather not valid and if it is not given you can assume false so your processes can go about verifying the validity of it..  This question has two directly polarizing opposites.  Gender does not, because you can't assume one or the other if it is not given. 

    This is the nature of booleans, anything else is and always will be an enumerator.



  • @MET said:

    @tster said:

    HOWEVER! Sometimes when asking for gender you are wanting to know if you should put Mr. or Ms. on the top of the letter you send them.  In such a case it makes more since to ask "Are you a man?" or "Are you a woman?" because that way you will get salutation that they desire.  Some transvestites might consider themselves men and some might consider themselves women.  

    And some I know go beyond Ms and say what they would really like is for you to use no salutation at all.  I think the idea is that for the vast majority of things your sex is unimportant, so why insist on it being specified every time your name is written?

    There is also a growing attitude among women to standardize on one salutation which can help, but that standard is not yet decided on.  Basically it hinges on the idea of "Why do I have to state my availability every time I meet someone?"  Think about it for a minute, when addressing a woman you always have to ask "Are you Miss or Mrs.?"  It has become another way of asking, Are you available and unmarried?

    My applications deal with the public a lot and these kinds of trends bring many strange requests for updates.


Log in to reply