• The Lone Ranger (unregistered) in reply to AlpineR

    O

    AlpineR:
    I'm surprised that a number of posters are defending this bit of code. There are two possible ways that this enum will be used:

    1. Bitmask. Status = 132 means Approved and Rejected. Um, yeah. Status = 32 means PaidFor but not Opened or Approved. Er.... These don't seem like sensible states for a bitmask.

    2. Single state. Status = 4 means Approved and Status = 128 means rejected. Okay, but why didn't you just use 1, 2, 3 instead of powers of 2 for the values? And if Status has a single state, then what does UnRejected mean? Don't we need to be able to say that an order is UnRejected and Approved, or UnRejected and PaidFor?

    This is the very definition of a WTF. I look at the enum and say "WTF is it supposed to do?".

    AlpineR



    It's pretty obvious you've done very little work with bitmasks.  If the mask says rejected and approved, it would sure make me find out why.

    Hi, Ho, Tonto, Away. . .


  • Truls (unregistered) in reply to chuck

    Ooops, kind of a reply to way back... probably didn't read far enough. Should have quoted...

  • Matt (unregistered) in reply to Otto

    The [Flags] attribute does nothing but give you a nicely formatted list of elements when you call ToString on the enum. You can still use bitFields without the flag. Try it...

  • Ricardo Stuven (unregistered)

    .NET 1.1:

    public enum BOOL
    {
      TRUE,
      FALSE,
      NOT_TRUE_OR_FALSE
    }
    BOOL variable = NOT_TRUE_OR_FALSE;

    .NET 2.0:

    bool? variable = null;  // or System.Nullable<BOOL>

     

    WTP? (what's the problem?) [:P] Oh, yes... some bad naming after all.

  • (cs) in reply to Xargon
    Xargon:
    public enum BOOL
    {
      TRUE,
      FALSE,
      NOT_TRUE_OR_FALSE
    }


    Why stop there?

    public enum BOOL-BALL
    {
    TRUE,
    FALSE,
    MOST_LIKELY,
    MY_SOURCES_SAY_FALSE,
    SIGNS_POINT_TO_TRUE,
    TRUE_DEFINITELY,
    OUTLOOK_TRUE,
    OUTLOOK_NOT_SO_TRUE,
    REPLY_HAZY_TRY_AGAIN
    }

     

    You forgot A_SUFFUSION_OF_YELLOW

  • (cs) in reply to nick8325
    nick8325:
    JohnO:

    Anonymous:
    Anonymous:
    Isn't the definition of boolean 2 values?


    No. http://en.wikipedia.org/wiki/Boolean_algebra

    You usually link a page that supports your assertion, not one that contradicts it.


    There's a difference between requiring two distinguished elements and allowing only two elements.

    The page has 6 examples of Boolean algebras with more than 2 elements, including one with a diagram.

    I think it's important to distinguish between *two* things here: a boolean datatype and a boolean algebra.  A boolean datatype (although possibly badly named) only has two possible values, by definition.  A clearer link would have been http://mathworld.wolfram.com/BooleanAlgebra.html, IMO.

  • George (unregistered) in reply to Roger

    Why is that a problem?  I'm sure that you wouldn't depend on TRUE being some magic value.

  • (cs) in reply to merrywing

    It's like in that movie, "White Men Can't Jump."  Sometimes, Billy, when a person says TRUE, they really mean FALSE.  And sometimes, when a person says FALSE, they really mean TRUE.  And sometimes when a person says TRUE or FALSE, they really mean NOT_TRUE_OR_FALSE.

  • (cs)
    Alex Papadimoulis:
    public enum OrderStatus
    {
      Opened = 1,
      PendingApproval = 2,
      Approved = 4,
      PendingAuthorization = 8,
      Authorized = 16,
      PaidFor = 32,
      Reject = 64,
      Rejected = 128,
      Deleted = 256,
      Removed = 512,
      UnRejected = 1024
    }

    It's quite clear that these are intended to be used as flags. This means all these conditions are not mutually exclusive. An order may have one or more of these statuses. That's even more worrisome than having a bool that can in a state that's neither true nor false. After all, perhaps the bool is representing qubits. :-)

  • (cs) in reply to Just Another WTF
    Anonymous:
    Anonymous:

    Gender is not the appropriate situation to apply boolean logic.  Chromosomally speaking, you can be boolean (presense or abscense) minded when talking about whether a Y chromosome on the sex gene exists, but in terms of physical appearance and culture, you could be dealing with an indivudual who is intersex could be classified as (Gender.MALE | Gender.FEMALE), depending on how the individual feels that day and where in his/her life (s)he is in before (optional) gender-correction surgery.

    The moral of the store is, use an enum here and put the options you need.  I would disagree with using NULL instead of an Other/Intersex value, as if you removed the person's undergarments there definately isn't NULL going on down there.  This situation occurs naturally in the population at large.

    Hope that cleared things up.

    Not to mention odd ball cases like XXY and other naturally occuring genetic situations.



    And Micheal Jackson.

  • (cs) in reply to B&#246;&#246;l
    Anonymous:
    Anonymous:
    Alex Papadimoulis:

    NOT_TRUE_OR_FALSE



    Beautiful! You can't even be sure, if it evaluates to true or to false.
    Shouldn't it be NOT_TRUE_OR_NOT_FALSE

    Not really.  The original was

    NOT (True OR False)

    Instead of

    (NOT True) OR (False)

  • (cs) in reply to Albatross

    The surrealist boolean:

    enum BOOL {
        TRUE,
        FALSE,
        A_FISH
    };


  • Rick Copeland (unregistered) in reply to JohnO

    Actually, the Wolfram link backs up multi-valued boolean algebra, as well:

    ...A Boolean algebra can be formally defined as a set B of elements a, b, ... with the following properties:...

    Two of the elements are called "0" and "1", but there can be many other values, as well.  Of course, neither link has any concept remotely similar to the original code.

  • (cs) in reply to eddieboston
    eddieboston:
    The surrealist boolean:

    enum BOOL {
        TRUE,
        FALSE,
        A_FISH
    };




    The teenager's boolean:

    enum BOOL {
    TRUE,
    FALSE,
    BUT_JENNYS_PARENTS_LET_HER_GO
    };

  • Rick Copeland (unregistered) in reply to Albatross
    Albatross:
    Anonymous:
    Anonymous:
    Alex Papadimoulis:

    NOT_TRUE_OR_FALSE



    Beautiful! You can't even be sure, if it evaluates to true or to false.
    Shouldn't it be NOT_TRUE_OR_NOT_FALSE

    Not really.  The original was

    NOT (True OR False)

    Instead of

    (NOT True) OR (False)



    Actually, the Wolfram link backs up multi-valued boolean algebra, as well:

    ...A Boolean algebra can be formally defined as a set B of elements a, b, ... with the following properties:...

    Two of the elements are called "0" and "1", but there can be many other values, as well.  Of course, neither link has any concept remotely similar to the original code.

  • (cs) in reply to eddieboston
    eddieboston:
    eddieboston:
    The surrealist boolean:

    enum BOOL {
        TRUE,
        FALSE,
        A_FISH
    };




    The teenager's boolean:

    enum BOOL {
    TRUE,
    FALSE,
    BUT_JENNYS_PARENTS_LET_HER_GO
    };



    The adolescent-boy-at-a-drivein's boolean:

    enum BOOL {
    TRUE,
    FALSE = TRUE
    };

  • Rick Copeland (unregistered) in reply to JohnO
    JohnO:
    nick8325:
    JohnO:

    Anonymous:
    Anonymous:
    Isn't the definition of boolean 2 values?


    No. http://en.wikipedia.org/wiki/Boolean_algebra

    You usually link a page that supports your assertion, not one that contradicts it.


    There's a difference between requiring two distinguished elements and allowing only two elements.

    The page has 6 examples of Boolean algebras with more than 2 elements, including one with a diagram.

    I think it's important to distinguish between *two* things here: a boolean datatype and a boolean algebra.  A boolean datatype (although possibly badly named) only has two possible values, by definition.  A clearer link would have been http://mathworld.wolfram.com/BooleanAlgebra.html, IMO.




    Actually, the Wolfram link backs up multi-valued boolean algebra, as well:

    ...A Boolean algebra can be formally defined as a set B of elements a, b, ... with the following properties:...

    Two of the elements are called "0" and "1", but there can be many other values, as well.  Of course, neither link has any concept remotely similar to the original code.

  • Mike (unregistered) in reply to pmagill

    Anonymous:
    Ok I think we all kinda agree on the BOOL definition as  aWTF.

    No, the bool definition is perfectly valid.  Usually when you see a 3rd value, it indicates that the boolean value should not be considered.

    For example, Lets say you were polling a set of objects:

    obj1.Vote = true;
    obj2.Vote = false;
    obj3.Vote = false;
    obj4.Vote = true;
    obj5.Vote = false;

    In this case, the majority voted false.   Now consider this:

    obj1.Vote = true;
    obj2.Vote = NoValue;
    obj3.Vote = NoValue;
    obj4.Vote = true;
    obj5.Vote = false;

    Here, obj2 and obj3 don't have a vote.  They don't care either way, so in this case their votes are not counted and the group votes true.

  • (cs)

    The WTF for me is 128 for Rejected, and 1024 for UnRejected.  How is "UnRejected" different than having the bit for "Rejected" be off?

  • Eli (unregistered) in reply to one in one-one-one
    Anonymous:
    mallard:
    Alex Papadimoulis:

    public enum OrderStatus
    {
      Opened = 1,
      PendingApproval = 2,
      Approved = 4,
      PendingAuthorization = 8,
      Authorized = 16,
      PaidFor = 32,
      Reject = 64,
      Rejected = 128,
      Deleted = 256,
      Removed = 512,
      UnRejected = 1024
    }


    Nice how he's used powers of 2 for all the possibilities...

    Would C# allow something to be (Opened | Removed) for instance?



    No problem there.   That way you can return a result as one value by just adding them up.



    Right so that should make it easier to search for records that are both Rejected and UnRejected...
  • s01 (unregistered) in reply to Rick Copeland

    To add fuel to the fire, the opposite of true isn't false.  It's not true.  It's how that entire multi valuable boolean thing.  

    Exampes:
    sad is not the opposite of happy.
    short is not the opposite of tall.
    wet is not the opposite of dry.

    After all, we can be just fine, average height or damp.  I'm making that my tagline.

  • Z. (unregistered) in reply to Colin

    what if we don't know their name is renee or chris?
    Shouldn't we default all names to Pat just in case?

  • Anonymous coward (unregistered) in reply to AndyW

    java.util.Boolean can be null, TRUE or FALSE.

    Not so weird.

    My favorite is 'unrejected.'

  • pmagill (unregistered) in reply to mrprogguy

    Hmm, tri state booleans.

    I see them as more of a schrodinger's cat kind of problem.  Let's say you have a web site that stores visitors in a database.  This database also marks them as registered if they do so.  Now you could see this registered field as a boolean, either TRUE or FALSE, they are registered or they are not, but since this is a database and you may be doing as few updates as possible, and registration was added after initial release, it allows NULL.  This then becomes tri-state.

    Now on to the cat.  We know what TRUE and FALSE represent in the registered field, but we have a third value of NULL.  As with the theoretical cat, we don't know if the visitor registered or not until we check it.  Once we check we notice that it's state is not yet defined so we safely (and rightly so) assume FALSE.  As schrodinger's cat suddenly dies we know that this visitor has not registered because, if he had, this value would explicitly state TRUE.

    So are tri state booleans really tri state?  In most cases I think not, but there could be a time when the cat is undead if you bury it in the local Pet Semetary.

  • (cs) in reply to Rick Copeland

    Actually, the Wolfram link backs up multi-valued boolean algebra, as well:

    That's why I said it would have been clearer to make his original point.  When I went to his original link, I had to go way down the page to see what he was talking about.

  • Jeremy (unregistered) in reply to Sum Fag
    Anonymous:
    Anonymous:
    Isn't the definition of boolean 2 values?


    No. http://en.wikipedia.org/wiki/Boolean_algebra


    Yes. http://en.wikipedia.org/wiki/Boolean_value
  • (cs) in reply to Roger
    Anonymous:

    Especially wonderful is that TRUE is the first value listed, so it has a value of 0.  FALSE has a value of 1.


    This is not really a huge problem, as C# requires conditionals to be boolean, therefore BOOL x; if (x) wouldn't compile. You would have to do if (x == BOOL.TRUE).
  • Brandon Bloom (unregistered)

    NOT_TRUE_OR_FALSE

    Wouldn't the compiler just optimize this to FALSE? ;-)

    (!1||0) == 0

  • LordHunter317 (unregistered) in reply to Colin
    Anonymous:
    Tri-bool: true, false, null.

    What's the problem with that?

    If you were to mark the gender of someone named "Rene" or "Chris", what would you mark it as?  Perfect instance of a boolean situation (male or female, obviously) and a third: unkown/not-sure.

    Hardly a WTF on that count.
    .NET 2.0 anyway already provdies this: Nullable<bool>, or bool?.
  • An apprentice (unregistered)

    Nobody's probably reading the third page of comments, but IMHO the true WTF is that the programmer's being inconsistent. It should have been:

        public enum BOOL
        {
          TRUE = 1,
          FALSE = 2,
          NOT_TRUE_OR_FALSE = 4
        }

  • ChiefCrazyTalk (unregistered) in reply to pmagill

    Anonymous:
    Hmm, tri state booleans.

    I see them as more of a schrodinger's cat kind of problem.  Let's say you have a web site that stores visitors in a database.  This database also marks them as registered if they do so.  Now you could see this registered field as a boolean, either TRUE or FALSE, they are registered or they are not, but since this is a database and you may be doing as few updates as possible, and registration was added after initial release, it allows NULL.  This then becomes tri-state.

    Now on to the cat.  We know what TRUE and FALSE represent in the registered field, but we have a third value of NULL.  As with the theoretical cat, we don't know if the visitor registered or not until we check it.  Once we check we notice that it's state is not yet defined so we safely (and rightly so) assume FALSE.  As schrodinger's cat suddenly dies we know that this visitor has not registered because, if he had, this value would explicitly state TRUE.

    So are tri state booleans really tri state?  In most cases I think not, but there could be a time when the cat is undead if you bury it in the local Pet Semetary.

     

    In your example, I agree, there is an implied false by the null value but that is by no means the case.  What if a user is asked a yes/no question, and the answer is stored on a website somewhere?   TRUE means Yes, FALSE means no, and NULL means they havent answered the question yet, so it is equally likely to go either way.  Sure, this doesn't meet the strict definition of "boolean" but in the real world of real problems, this is a valid consideration.

  • Ugh (unregistered) in reply to An apprentice

    If a variable is "Boolean" it is true or false, and that's it.
    If the variable can have other values, it is not "Boolean" it is a different type of logical construct.

    There are plenty of logical systems that have more than true or false, THEY JUST ARE NOT "BOOLEAN".

    Yeesh


  • (cs)

    With some years of business processing behind me I can assure all and sundry that the state diagram for an order can be as complex as the first enum suggests, in some companies  even more so.  A case can be made for the value of ALL the implied states, including unrejected, which surely is not the same as any of the others listed.

    I seriously expect that these make sense as discrete states.  But that's only because I am thinking about the life of an order in a complex company.

    Although it is kinda hard to read, in the old days, printing a string of unspaced single characters to indicate status was commonplace, even for mutually exclusive states.  Thus the use of binary values might be explained.

    The disservice to us is the invitation to imagine the rest of the system.  I've worked on many sound process systems that used complex state models with total validity.

    I think the choice of the name BOOL is an unfortunate error of ignorance, rather than an invalid set of ennumerated values.

    Is it a WTF to produce somewhat hard to understand code?  I dunno - there's lots out there.

    Personally, I think this is only a WTF if F = "French Kiss with no tongue (Madeline Kahn RIP)"

  • Truls (unregistered) in reply to Ugh

    <FONT color=#000000>pmagill:</FONT>

     Hmm, tri state booleans.

    I see them as more of a schrodinger's cat kind of problem.  Let's say you have a web site that stores visitors in a database.  This database also marks them as registered if they do so.  Now you could see this registered field as a boolean, either TRUE or FALSE, they are registered or they are not, but since this is a database and you may be doing as few updates as possible, and registration was added after initial release, it allows NULL.  This then becomes tri-state.

    Now on to the cat.  We know what TRUE and FALSE represent in the registered field, but we have a third value of NULL.  As with the theoretical cat, we don't know if the visitor registered or not until we check it.  Once we check we notice that it's state is not yet defined so we safely (and rightly so) assume FALSE.  As schrodinger's cat suddenly dies we know that this visitor has not registered because, if he had, this value would explicitly state TRUE.

    So are tri state booleans really tri state?  In most cases I think not, but there could be a time when the cat is undead if you bury it in the local Pet Semetary.

    That doesn't work at all. In the schrodinger's cat problem you don't assume one or the other or neither. You assume both because you can't observe it it. So he can observe the database (with respect to the program)... s/he's just to lazy to create better checking.

    meaning it exists partly as each simultaneously

  • Random (unregistered) in reply to Sum Fag
    Anonymous:
    Anonymous:
    Isn't the definition of boolean 2 values?


    No. http://en.wikipedia.org/wiki/Boolean_algebra


    Boolean does imply bivalent though, which is probably what the OP was vaguely fumbling for. If you want something that's no bivalent then you get a Heyting algebra.
  • (cs) in reply to mrprogguy
    mrprogguy:
    The WTF for me is 128 for Rejected, and 1024 for UnRejected.  How is "UnRejected" different than having the bit for "Rejected" be off?

    Decision states. I would interpret UnRejected as someone reversing a decision to Reject This is not the same as a rejection never having occured.

  • trav (unregistered)
    Alex Papadimoulis:

    public enum OrderStatus
    {
    Opened = 1,
    PendingApproval = 2,
    Approved = 4,
    PendingAuthorization = 8,
    Authorized = 16,
    PaidFor = 32,
    Reject = 64,
    Rejected = 128,
    Deleted = 256,
    Removed = 512,
    UnRejected = 1024
    }


    Looks like the programmer is fiddling with his bits.  BAD PROGRAMMER, BURN IN THE FIRES OF PURGATORY HELL!
  • (cs) in reply to trav

    I do like how he just makes up a boolean system with a nice rejected unrejected. It's like it can be neither, both, rejected, or unrejected. And then he tries to make up his own system of bool to match it. Wonder if he will add a third flag for user_dead or user_smacking_computer_violently when the user submits one that is unrejected followed by another that is rejected.

  • Derek (unregistered) in reply to Gene Wirchenko
    Gene Wirchenko:
    So you have found a bug.  It is hardly "You know, this forum software is pretty much entirely nonfunctional with Firefox."  That is a typical end user behaviour and not a good one.  "Physician, heal thyself."

    Sincerely,

    Gene Wirchenko

    Well, I've managed to do that more than once.  I thought it just didn't work at all.  It wasn't until I tried to quote his post that I realized it wasn't an always-bug.

    - - -

    As far as the BOOL, I'd say that the WTF is that its third state is so poorly named.  NOT_TRUE_OR_FALSE? What that that even mean?

    UNKNOWN, INDETERMINATE (ala tribool), and maybe even NULL would all be acceptable.  The choice of NOT_TRUE_OR_FALSE is just wierd.
  • Anonymous (unregistered)
    Alex Papadimoulis:

    public enum BOOL
    {
      TRUE,
      FALSE,
      NOT_TRUE_OR_FALSE
    }


    This programmer is a bit outdated... the future of boolean algebra is float. 0.0 is false, 1.0 is true, and everything between 0.0 and 1.0 would be a valid boolean, but neither true nor false.
  • (cs) in reply to felix
    felix:
    Anonymous:

    any attempt to "extend" Boolean logic to include a ternary state is also the work of a dumbass. Including nullable bools.



    Are you that sure? And what do you put in your database when you don't know the state of a field, or the field just doesn't apply? Want an example? A list of software where each entry has a "working" field, meaning "does this program work?" Obviously, a program can either be working or not... but what if you haven't tested it yet?

    But you appealed to a higher authority. Let me appeal to several others: the creators of all those SQL databases out there. According to you, they're all dumbasses, right? And you must be Edgar Codd himself? Oh wait, you can't be. Codd's 3rd rule explicitly says "The DBMS must allow each field to remain null (or empty). [...]" (see on Wikipedia).

    <?xml:namespace prefix = personal /><personal:rant>I have a biiig problem with people who argue an issue though they haven't read one bit about it, or at least talked to someone familiar with the matter. Naturally, when invited to do so, they usually refuse. I guess changing opinions is exceedingly difficult to some people. Living in one's own fantasy world and all that...</personal:rant>

     

    <FONT face=Arial size=2>Now there is something for 'Quote of the week, on dbdebunk.com.</FONT>

    <FONT face=Arial size=2>In your case, a tested program is a specialized, ‘derived’ or an extended version of a 'program' so would be propagated to it's own relation, along with any other attributes related to 'tested' software... I think you will find that under 2nd Normal Form. </FONT>

    <FONT face=Arial size=2>Codd only suggested 3vl logic, the problem was he then found himself suggesting 4vl (true, false, missing, not applicable). Some research went into this and they ended up with 20 reasons for not existent data. </FONT>

    <FONT face=Arial size=2>C.Date, H.Darwen, F.Pascal and a few other proponents of the Relational Model rejected 3vl, and if you check the wikipedia entry on Relational Theory / Modeling, the first paragraph rejects the concept of 'Null'.</FONT>

    <FONT face=Arial size=2>And yes, SQL is dumb, confused and general not up to the job, and certainly not something I would choose as a ‘Higher authority’
    </FONT>

  • dio (unregistered) in reply to pmagill
    Anonymous:
    I guess this has to do with teh appearance of the 1 and 0.  One of them is obviously more of a phalic symbole then the other.  Of course this could be the root cuase of many fallicies.


    So... 0 is obviously male then? Looks like a piece of anatomy and 1 looks obviously female.

    Or did you mean the other way? I can guess both ways, they're equally likely.
  • Froot (unregistered) in reply to Derek
    Anonymous:

    (!TRUE  ||  FALSE ) =  FALSE

    enum
    {
        TRUE,
        FALSE,
        FALSE
    }

    Beautiful.

     

    P.S.  You know, this forum software is pretty much entirely nonfunctional with Firefox.  <insert comment="" about="" the="" real="" wtf=""></insert>



    Then how did you post? You seem to have a funny definition of "entirely nonfunctional".


  • (cs) in reply to Grovesy

    Am I the only person who realizes that "the real wtf" is the *entire system*, not those snippets of code?  I'm not sure whether Alex or the submitter even intended them to be WTFs on their own.

    I think it's constructive to debate the legitimacy of those two excerpts (in fact I learn quite a bit from The Daily WTF by reading through these discussions), but it seems only a handful of people have tried to picture what the entire system might look like.  I think a lot of people are failing to realize how terrible the system must be, given that a) we're told it *is* a WTF system, and b) it uses these code snippets -- in horrific ways, no doubt.

    Suppose you are a new developer hired to maintain this system.  Had the previous authors used an enumeration that was *not* a set of flags, you would know right away that an order can be in at most one of those states at any time (and if you trust them not to WTF-it-up, you know it must be in exactly one of those states at all times).

    Instead, we have no idea which flags are mutually-exclusive and which can be on at the same time (comments would have been nice!).  It's also possible for the order to be in NONE of those states, i.e. 0.  Maybe we can assume that Accepted and Rejected are mutually-exclusive, but would you really feel confident in that assumption given the already-terrible state of the system? ;)

    I wonder:  is the existence of both Rejected and UnRejected the result of a dev needing a way to determine whether a report is not rejected, and not realizing that they can just use "if (!(status & Rejected))", they made a new flag called UnRejected?

  • (cs) in reply to Bill307
    Bill307:

    Am I the only person who realizes that "the real wtf" is the *entire system*, not those snippets of code?  I'm not sure whether Alex or the submitter even intended them to be WTFs on their own.

    I think it's constructive to debate the legitimacy of those two excerpts (in fact I learn quite a bit from The Daily WTF by reading through these discussions), but it seems only a handful of people have tried to picture what the entire system might look like.  I think a lot of people are failing to realize how terrible the system must be, given that a) we're told it *is* a WTF system, and b) it uses these code snippets -- in horrific ways, no doubt.

    Suppose you are a new developer hired to maintain this system.  Had the previous authors used an enumeration that was *not* a set of flags, you would know right away that an order can be in at most one of those states at any time (and if you trust them not to WTF-it-up, you know it must be in exactly one of those states at all times).

    Instead, we have no idea which flags are mutually-exclusive and which can be on at the same time (comments would have been nice!).  It's also possible for the order to be in NONE of those states, i.e. 0.  Maybe we can assume that Accepted and Rejected are mutually-exclusive, but would you really feel confident in that assumption given the already-terrible state of the system? ;)

    I wonder:  is the existence of both Rejected and UnRejected the result of a dev needing a way to determine whether a report is not rejected, and not realizing that they can just use "if (!(status & Rejected))", they made a new flag called UnRejected?

     

    <!--StartFragment --> no no, I assure you, I know the entire system was a real WTF,

    I'll give you a clue on this system..... see the previous WTF, 'yeessssssssssssss noooooooooo' (same place)...

  • (cs) in reply to Grovesy

    FILE_NOT_FOUND

  • Doug (unregistered) in reply to Colin

    Funny, I actually have a system that has an enum of "male", "female", "unknown". At first when tracking members there were quite a few I'd never met and I hadn't a clue what gender their name even might be. Now I know what gender everybody is, but there are a few members/users that are actually 4-6 people of mixed genders, so they end up as unknown. The mapping of more than one person to a member record is extremely rare, and is not important enough to account for it in all the systems already written. Unknown handles those rare cases already.

  • (cs) in reply to dio

    Anonymous:
    Anonymous:
    I guess this has to do with teh appearance of the 1 and 0.  One of them is obviously more of a phalic symbole then the other.  Of course this could be the root cuase of many fallicies.


    So... 0 is obviously male then? Looks like a piece of anatomy and 1 looks obviously female.

    Or did you mean the other way? I can guess both ways, they're equally likely.

    Lol, are you from Earth?  0 is a hole and 1 is a rod.  Perhaps the rest of us are missing some clever, different way of looking at it?

  • Derek (unregistered) in reply to Froot
    Anonymous:

    Then how did you post? You seem to have a funny definition of "entirely nonfunctional".


    Recently, a lot of experts in the browser field have begun to agree that it's likely that multiple browsers can coexist on a single computer.  They say it's probably really complicated, but possible.
  • (cs) in reply to eddieboston
    eddieboston:
    eddieboston:
    eddieboston:
    The surrealist boolean:

    enum BOOL {
        TRUE,
        FALSE,
        A_FISH
    };




    The teenager's boolean:

    enum BOOL {
    TRUE,
    FALSE,
    BUT_JENNYS_PARENTS_LET_HER_GO
    };



    The adolescent-boy-at-a-drivein's boolean:

    enum BOOL {
    TRUE,
    FALSE = TRUE
    };



    The second-most-highly-paid-consultant's boolean:

    enum BOOL {
        TRUE,
        FALSE,
        "NULL"
    }

Leave a comment on “Enumerating The Difficulties”

Log In or post as a guest

Replying to comment #:

« Return to Article