| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Next » |
|
Isn't the definition of boolean 2 values? I don't want to imagine
the innards where you can have conditions that arent true or false |
Yes! No... Maybe...? |
|
Didn't you see the movie "Tron"? They had "bits" that had 3 states: yes, no and neither of the above.
|
Nice how he's used powers of 2 for all the possibilities... Would C# allow something to be (Opened | Removed) for instance? |
|
I'm new to reading the daily wtf ( great site by the way ).. Do you
guys see this alot, people rewriting or replacing fundamental pieces of a language? |
|
having three boolean values kind of goes along with having status flags for rejected (128) and unrejected(1024) what is it if it is neither? But then wait...there is reject (64) also...
|
|
Well... Databases never had boolean values (because of null), so perhaps there is an explanation for the 2nd enum...
|
Re: Enumerating The Difficulties
2006-02-22 12:28
•
by
OneFactor
|
Yup, very common for searching and stuff. Does common mean good idea? true, false, maybe... |
Beautiful! You can't even be sure, if it evaluates to true or to false. |
|
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. |
|
Especially wonderful is that TRUE is the first value listed, so it has a value of 0. FALSE has a value of 1. |
Re: Enumerating The Difficulties
2006-02-22 12:34
•
by
Anonymous coward!
|
|
I think the order status is some sort of mask. So you can have an open, authorized, rejected order!
|
|
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. But 'male or female' isn't a boolean situation at all. It's just something that 'usually' has two states, whereas a boolean 'usually' has two states. To phrase that as a boolean, you'd have to say it was either 'male? (true/false)' or 'female? (true/false)'. And then you'd have to quibble semantics with the gender crew for the rest of the project's duration. Three-state logic is common in logic simulation: a binary signal can either be true, false, or unknown ('x'), and that's perfectly reasonable because we can reason about thebehaviour of a circuit in the presence of unknown values ( 1 | x is equal to 1, for instance). Of course, things get even more amusing when you add in the fourth logic state, 'z'... |
|
As long as you don't specify [FlagsAttribute] its just a plain enum, not a set. Still quite some values thou
|
No. http://en.wikipedia.org/wiki/Boolean_algebra |
Neither has C (C++ has, though. C# probably, too). |
|
Thats the first and only TROOL, tri state boolean! Every 17º generation language will have it, to be prepared for quantum computing. You have to update your resumes. Leo |
|
There's nothing wrong with the idea of a tristate conceptually; however the implementation is really lame. You simply wouldn't call it a "BOOL" ... it's confusing to read. This probably wasn't a 2.0 app but if so, you could just make a nullable bool. Or, a struct. As for the first enum, the flags attribute is missing (a mistake, not a wtf) but based on the descriptions (which could be cleaned up a tad, but hey), it looks more like a single state is all that could apply. That could be how it's used ... just because the numbers suggest a bitwise format doesn't mean it's being used that way. Bad decisions for sure but not really that much of a WTF here. |
Then why call it a boolean? |
The gender would be of type 'Gender, which would have allowable values of 'Male, Female'. Uknown would be flagged in a system that allows nullable types (such as C# 2.0, or SQL) as being Null. Null / Missing / Uknown would not belong to the 'Geneder' Type because Uknown is not a Gender. (Besides in C# 2.0 and SQL Null is a valu) The proposition 'Rene is Male' would evaluate to true or false (or possibly Null if your feel like abusing the Relational Model). It should never evaluate to 'Neither True or False' |
Holy crap, talk about quibbling. I mean...damn.
Do you want to try that one again? If both are 'usually' two stated, then what's your problem? |
|
Enumerating 3 states was probably in response to dealing with the database backend.
The order status is definitely a set of flags. There's no reason not to have conflicting flags if precedence is handled in code or if an exception is raised when an invalid flag combination is set. Where's the wtf? |
because the domains 'Gender' and 'Boolean' are diffrent and imply diffrent meaning, therfore you would never express a gender as a boolean. True, to my knowledge is not a Gender.
|
|
"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."
This is just to good old problem of representing unknown information on a database, on which many people have written a fair amount, of which many, many more have read nothing. One classic problem: there is a difference between using a third value to represent "the real-world entity represented by this record has a value for this, but it is unknown," "the entity represented could have a value for this in the real world, but it actually happens not to have one," and "the real world is such that the entity described can't have a value for this." In short, people tend to systematically confuse data that represents facts about the real-world entities in questions and metadata about the completeness of the representation. |
|
So guys...
Is this BRILLANT or not? |
That would be BRILLANT or ~BRILLANT {sounds a bit Shakespearean, eh?} |
Re: Enumerating The Difficulties
2006-02-22 12:58
•
by
Gene Wirchenko
|
Quoting from that page: "A Boolean algebra is a set A, supplied with two binary operations (logical AND), (logical OR), a unary operation (logical NOT) and two elements 0 (logical FALSE) and 1 (logical TRUE), such that, for all elements a, b and c of set A, the following axioms hold:"Sincerely, Gene Wirchenko |
I believe "Rene" is a male name... the female version is "Renee" (give or take an accent mark or two) Compare fiance and fiancee. |
|
I'm willing to bet the application contained the following code: If (orderCondition==orderstatus.UnRejected || orderApproved==BOOL.NOT_TRUE_OR_FALSE) {.. }
|
Re: Enumerating The Difficulties
2006-02-22 13:01
•
by
one in one-one-one
|
No problem there. That way you can return a result as one value by just adding them up. |
Re: Enumerating The Difficulties
2006-02-22 13:02
•
by
Gene Wirchenko
|
A female version is "Renee", but I have also seen "Rene" used as a female name. For that matter, there are the names "Gene" and "Jean". The former is generally male, but I have encountered one female "Gene". Then, there are the people who insist on trying to spell my name "J-e-a-n", and sometimes even when I spell it to them. Sincerely, Gene Wirchenko |
Oh god yeah... just take a look at Better C post ( http://www.thedailywtf.com/forums/60255/ShowPost.aspx ). It's obligatory to think the entire forum software is the biggest WTF too. |
|
It's the UnRejected status that gets me.. If something is UnRejected, surely it would go back to a state of {opened, pending approval, approved, .... .etc).. with some note attached. UnRejected appears to be a terminal state. |
Re: Enumerating The Difficulties
2006-02-22 13:08
•
by
Bööl
|
Shouldn't it be NOT_TRUE_OR_NOT_FALSE |
Bullee! Would you like to see my gender dictionary? Lotsa ambiguity. Name ends with 'o' -- probably male Name ends with 'a' -- probably female. And, doubtless, many, many exceptions. This is not a real WTF. Alex posted early to stop the chatter on yesterday's WTF. Not Shirley |
|
Ugh, re the true/false boolean thing, the third form may be a form of mu, not enough information to discern. Think of a person who never makes a choice between red or blue. Logically, it's red vs not-red here in the concept of booleans. I'm betting the 3rd means unknown. Bad naming in that case.
Assigning constants, I do the same thing sometimes out of habbit. I work a lot w/ flags that work with combinatorics. I.e. READ, WRITE, EX_LOCK and so on. I'm hoping, in good faith, that the number assignments were just habbit, and not for silliness like (REJECTED|NOT_REJECTED) type crap. I'm hopin' for the best here. :) |
There's nothing particularly wrong with this *if* it was prefixed with the [Flags] attribute. Then he could do something like this: OrderStatus myStatus = OrderStatus.Opened | OrderStatus.PendingApproval;...and so forth. The WTF here is in the choices of his flags, since some of them probably don't make sense together.. Like: OrderStatus myStatus = OrderStatus.PendingAuthorization | OrderStatus.Authorized;What would this mean? It's entirely possible with that enum, so there must be logic in the code to eliminate that as a possible case. It's just bad design of a bitmask, really. But it probably corresponds to some other stupid structure elsewhere, so it might not be a WTF on the author's part, as he might have no choice in the data coming from elsewhere. |
|
(!TRUE || FALSE ) = FALSE enum Beautiful.
P.S. You know, this forum software is pretty much entirely nonfunctional with Firefox. <insert comment about "the real WTF"> |
Re: Enumerating The Difficulties
2006-02-22 13:20
•
by
Sundown Slim
|
|
Yeah, if DOS batch files did it, it must be OK. The bigger WTF here is the business um... logic. I'd love to see how they unreject an order after it's been deleted and removed.
|
and PaidFor [8-|] |
|
What a doof! Clearly what he means instead of NOT_TRUE_OR_FALSE is FILE_NOT_FOUND.
|
|
can someone explain why there is anything wrong with this? i think more programmers should use bitmasks. this seems like it would be especially useful for defining supersets so that you can compare the status of an order to a predefined set of conditions without having to write some long if...ifelse or switch statement.
|
Re: Enumerating The Difficulties
2006-02-22 13:25
•
by
BlackTigerX
|
whatta newbie... of course you can have more than 2 values!! yes, no, maybe true, false, NULL and of course true, false, FileNotFound [:P] |
Re: Enumerating The Difficulties
2006-02-22 13:26
•
by
BlackTigerX
|
oops... you beat me to that... of course is that clear!! (we're so WTF) |
Re: Enumerating The Difficulties
2006-02-22 13:27
•
by
BlackTigerX
|
WTF!!... this happens all the time!, clearly you guys are not in that type of bussiness! |
|
http://www.boost.org/doc/html/tribool.html
Boost has a boolean with 3 states, so it's not basically crap, but the implementation is crappy, unless you compare always against TRUE,FALSE or NOT_TRUE_OR_FALSE but don't dare to forget that, or you'll run into a bunch of problems. |
Re: Enumerating The Difficulties
2006-02-22 13:33
•
by
StarfishC
|
More like NEITHER_TRUE_NOR_FALSE. (Imagine if it was NONE_OF_THE_ABOVE!) By the way, I have never had a problem with Firefox 1.5. Perhaps the problem lies in front of your monitor. |
|
Ok I think we all kinda agree on the BOOL definition as aWTF.
The other Enum is a bit more flaky. I consider this a true WTF also for the following reasons: This is defined as a bit flag enum. Essentially each value is equal to one bit in the binary list of bits. This should be used only when the different states are NOT mutually exclusive as using a bit flagged enumerator by definition allows any of the bits to be set on or off regardless of the state of the others. Since some of these states seem mutually exclusive of each other this should be a straight enum with sequential numbering. So: Straight Enumerator for mutually exclusive values. Bitflags for concurrent state values. |
Re: Enumerating The Difficulties
2006-02-22 13:35
•
by
John Smallberries
|
|
if((o & OrderStatus.Rejected) == OrderStatus.Rejected && (o & OrderStatus.UnRejected) == OrderStatus.UnRejected)
o |= OrderStatus.Removed | OrderStatus.Deleted; Sweet. |
| « Prev | Page 1 | Page 2 | Page 3 | Page 4 | Page 5 | Next » |