• OurName (unregistered) in reply to SomeCoder
    SomeCoder:
    I would really like to know just what goes on in the mind of someone who is writing this. I just can't imagine how this could ever come into existence...
    Get an either unexperienced or dumb (or both) coder and tell him "OurOracle does not support boolean columns natively". He will come up with a replacement...
  • (cs) in reply to yet another Matt
    yet another Matt:
    By making it 'Our' boolean he manages to make it sound so much more romantic. It's no longer YourBoolean, its OurBoolean. It's no longer YourCar, its OurCar. It's no longer YourCDs, its OurCDs.

    I wonder who will get which half of the Boolean when the relationship breaks down.

    Dibs on True!

    All OurBoolean belong to You!

  • (cs) in reply to snoofle
    snoofle:
    Fixed:
    ThePants999:
    It "optimizes for memory usage" by creating a 10-element list to hold boolean values...
    What in the world makes you think that the default allocation of <10> is anywhere near enough to store a boolean value?

    1 TRUE 2 "TRUE", "True", "true" 5 FALSE 6 "FALSE", "False", "false" 9 true 10 false 11 Boolean.TRUE 12 Boolean.FALSE 13 "Y", "Yes, "YES", "y", "yes" 18 "N", "No", "NO", "n", "no" 23 FileNotFound 24 Maybe, MAYBE, maybe 27 Possibly, POSSIBLY, possibly 30 SOMETIMES, Sometimes, sometimes 33 TrueFalse, truefalse, TRUEFALSE, TF, tf 38 VERYTRUE, VeryTrue, verytrue, VT, Vt, vt 44 VERYFALSE, VeryFalse, veryfalse, VF, Vf, vf 50 UNKNOWN, Unknown, unknown, U, u 55 TRYAGAINLATER,TryAgainLater,tryagainlater,TAL,Tal,tal 61 TheFutureIsUnclear 62 SegFault 63 Paula 64 WTF 65 NOTTRUE,NotTrue,nottrue,NT,Nt,nt 71 NOTFALSE,NotFalse,notfalse,NF,Nf,nf

    Thanks to all for corrections/ommissions

    Still not good enough for prime time -- it's a Java object, isn't it? And we all know that there's no such thing as a default value for a boolean, and we can't rely on future versions of Java being compatible with the "null" object. So:

    72 null to mimic required current Java behaviour. 73 Null in case Sun changes naming conventions in future versions of Java. 73 NULL for when it's so really, really null that you need to shout about it. Also handy for JNI interfaces. 74 undef for Perl compatibility. 75 Nil for compatibility with most other dynamic languages. 76 IsNotIsNotNyahNyahNyah for the special Playground Edition.

    Of course, you'd need to wrap all of these up in a try/catch/throw NullReferenceException, but that's a small price to pay for completeness.

  • (cs) in reply to rycamor
    rycamor:
    I can't believe you left out the Magic 8-ball list:
    ● As I see it, yes
    ● Ask again later
    ● Better not tell you now
    ● Cannot predict now
    ● Concentrate and ask again
    ● Don't count on it
    ● It is certain
    ● It is decidedly so
    ● Most likely
    ● My reply is no
    ● My sources say no
    ● Outlook good
    ● Outlook not so good
    ● Reply hazy, try again
    ● Signs point to yes
    ● Very doubtful
    ● Without a doubt
    ● Yes
    ● Yes - definitely
    ● You may rely on it
    

    That's more like a Magic 20-ball list

  • Christophe (unregistered) in reply to snoofle
    snoofle:
    ThePants999:
    It "optimizes for memory usage" by creating a 10-element list to hold boolean values...
    What in the world makes you think that the default allocation of <10> is anywhere near enough to store a boolean value?

    1 TRUE 2 "TRUE" 3 "True" 4 "true" 5 FALSE 6 "FALSE" 7 "False" 8 "false" 9 true 10 false 11 Boolean.TRUE 12 Boolean.FALSE 13 "Y" 14 "Yes" 15 "YES" 16 "y" 17 "yes" 18 "N" 19 "No" 20 "NO" 21 "n" 22 FileNotFound

    This also eases regionalization, as in: 23 Ja 24 Nein 25 Oui ...

  • (cs) in reply to StarLite
    StarLite:
    An apprentice:
    s.:
    And imagine how extendable that code is!

    Say, you want to port your code to a quantum computer. You just modify the OurBoolean class to return a float in range of [0-1] instead of strings, and you're home!

    Don't forget to initialise your list with all possible floats.

    That might take while, but that shouldn;t be a problem for the quantum computer to do automatically. You'd first need to write a program for that tho, which will have toinclude OurBoolean, which will have to be initialized bij a quantum computer, which will need a program that...

    I think there might be a problem in that ;)

    Initializing a list to hold all possible 32-bit float values (IEEE 754) would take up 16 gigabytes of memory, just for the floats themselves (so at least double it for the pointers and other stuff in the list structure), and should only take a few seconds to create, on any relatively modern machine that has that much memory.

  • (cs)

    Aw man, I kept thinking the title should be "OurBoolean, OurSelves"

    [/dating myself]

  • (cs) in reply to slavdude
    slavdude:
    [/dating myself]

    You need a girlfriend.

  • (cs)

    OurBoolean.getList().clear();

  • Tom (unregistered)

    was getList() ever used?

  • (cs)

    No one has mentioned the very first WTF: obtaining a boolean value from a database as a String. This is almost certainly the fault of the database designer, who's probably one of those DBAs who thinks he/she should implement as much application logic in the database as possible, so instead of storing booleans as the smallest allowed integer types (I think Sybase has a 1-bit data type), he/she used varchar(5), which cannot be retrieved using ResultSet.getBoolean.

  • Obi Wan (unregistered) in reply to BinaryPhalanx
    BinaryPhalanx:
    You left out a couple:

    YEs yES yEs nO

    You know, a line HAS to be drawn SOMEWHERE, even in WTF code.

  • rycamor (unregistered) in reply to suzilou
    suzilou:
    rycamor:
    I can't believe you left out the Magic 8-ball list:
    ● As I see it, yes
    ● Ask again later
    ● Better not tell you now
    ● Cannot predict now
    ● Concentrate and ask again
    ● Don't count on it
    ● It is certain
    ● It is decidedly so
    ● Most likely
    ● My reply is no
    ● My sources say no
    ● Outlook good
    ● Outlook not so good
    ● Reply hazy, try again
    ● Signs point to yes
    ● Very doubtful
    ● Without a doubt
    ● Yes
    ● Yes - definitely
    ● You may rely on it
    

    That's more like a Magic 20-ball list

    It's an 8-ball from billiards, but it has more than 8 answers: http://en.wikipedia.org/wiki/Magic_8-Ball

  • Stiggy (unregistered) in reply to real_aardvark
    real_aardvark:
    snoofle:
    Fixed:
    ThePants999:
    It "optimizes for memory usage" by creating a 10-element list to hold boolean values...
    What in the world makes you think that the default allocation of <10> is anywhere near enough to store a boolean value?

    1 TRUE 2 "TRUE", "True", "true" 5 FALSE 6 "FALSE", "False", "false" 9 true 10 false 11 Boolean.TRUE 12 Boolean.FALSE 13 "Y", "Yes, "YES", "y", "yes" 18 "N", "No", "NO", "n", "no" 23 FileNotFound 24 Maybe, MAYBE, maybe 27 Possibly, POSSIBLY, possibly 30 SOMETIMES, Sometimes, sometimes 33 TrueFalse, truefalse, TRUEFALSE, TF, tf 38 VERYTRUE, VeryTrue, verytrue, VT, Vt, vt 44 VERYFALSE, VeryFalse, veryfalse, VF, Vf, vf 50 UNKNOWN, Unknown, unknown, U, u 55 TRYAGAINLATER,TryAgainLater,tryagainlater,TAL,Tal,tal 61 TheFutureIsUnclear 62 SegFault 63 Paula 64 WTF 65 NOTTRUE,NotTrue,nottrue,NT,Nt,nt 71 NOTFALSE,NotFalse,notfalse,NF,Nf,nf

    Thanks to all for corrections/ommissions

    Still not good enough for prime time -- it's a Java object, isn't it? And we all know that there's no such thing as a default value for a boolean, and we can't rely on future versions of Java being compatible with the "null" object. So:

    72 null to mimic required current Java behaviour. 73 Null in case Sun changes naming conventions in future versions of Java. 73 NULL for when it's so really, really null that you need to shout about it. Also handy for JNI interfaces. 74 undef for Perl compatibility. 75 Nil for compatibility with most other dynamic languages. 76 IsNotIsNotNyahNyahNyah for the special Playground Edition.

    Of course, you'd need to wrap all of these up in a try/catch/throw NullReferenceException, but that's a small price to pay for completeness.

    77 TheseAreNotTheDroidsYouAreLookingFor

  • MyBoolean (unregistered)

    The real WTF is they used VB.

  • Stiggy (unregistered) in reply to MyBoolean
    MyBoolean:
    The real WTF is they used VB.

    No they didn't. There's no line numbers.

  • Paul L (unregistered) in reply to VGR
    VGR:
    No one has mentioned the very first WTF: obtaining a boolean value from a database as a String ... he/she used varchar(5), which cannot be retrieved using ResultSet.getBoolean.
    Nope. He used varchar2(30) for all boolean values.

    Seriously. I'm looking at the schema right now.

  • immibis (unregistered)

    TRWTF is that he uses toUpperCase like its a field.

    result.toUpperCase.equals(...)
  • raipe (unregistered) in reply to ChZEROHag

    Here's on more:

    kyllä Kyllä kYllä KYllä kyLlä KyLlä kYLlä KYLlä kylLä KylLä kYlLä KYlLä kyLLä KyLLä kYLLä KYLLä kyllÄ KyllÄ kYllÄ KYllÄ kyLlÄ KyLlÄ kYLlÄ KYLlÄ kylLÄ KylLÄ kYlLÄ KYlLÄ kyLLÄ KyLLÄ kYLLÄ KYLLÄ ei Ei eI EI

  • deadimp (unregistered)

    Just wait 'til that guy does something with real numbers...

    Shudders too

  • Pete (unregistered) in reply to yet another Matt

    I find the people who most loudly assert TRUE are usually the ones returning FALSE.

  • (cs) in reply to VGR
    VGR:
    No one has mentioned the very first WTF: obtaining a boolean value from a database as a String. This is almost certainly the fault of the database designer, who's probably one of those DBAs who thinks he/she should implement as much application logic in the database as possible, so instead of storing booleans as the smallest allowed integer types (I think Sybase has a 1-bit data type), he/she used varchar(5), which cannot be retrieved using ResultSet.getBoolean.
    I'm glad I'm not the only one who noticed that ResultSet.getBoolean() would eliminate this problem if the column were actually Boolean.
  • AndStuff (unregistered) in reply to Stiggy
    Stiggy:
    real_aardvark:
    snoofle:
    Fixed:
    ThePants999:
    It "optimizes for memory usage" by creating a 10-element list to hold boolean values...
    What in the world makes you think that the default allocation of <10> is anywhere near enough to store a boolean value?

    1 TRUE 2 "TRUE", "True", "true" 5 FALSE 6 "FALSE", "False", "false" 9 true 10 false 11 Boolean.TRUE 12 Boolean.FALSE 13 "Y", "Yes, "YES", "y", "yes" 18 "N", "No", "NO", "n", "no" 23 FileNotFound 24 Maybe, MAYBE, maybe 27 Possibly, POSSIBLY, possibly 30 SOMETIMES, Sometimes, sometimes 33 TrueFalse, truefalse, TRUEFALSE, TF, tf 38 VERYTRUE, VeryTrue, verytrue, VT, Vt, vt 44 VERYFALSE, VeryFalse, veryfalse, VF, Vf, vf 50 UNKNOWN, Unknown, unknown, U, u 55 TRYAGAINLATER,TryAgainLater,tryagainlater,TAL,Tal,tal 61 TheFutureIsUnclear 62 SegFault 63 Paula 64 WTF 65 NOTTRUE,NotTrue,nottrue,NT,Nt,nt 71 NOTFALSE,NotFalse,notfalse,NF,Nf,nf

    Thanks to all for corrections/ommissions

    Still not good enough for prime time -- it's a Java object, isn't it? And we all know that there's no such thing as a default value for a boolean, and we can't rely on future versions of Java being compatible with the "null" object. So:

    72 null to mimic required current Java behaviour. 73 Null in case Sun changes naming conventions in future versions of Java. 73 NULL for when it's so really, really null that you need to shout about it. Also handy for JNI interfaces. 74 undef for Perl compatibility. 75 Nil for compatibility with most other dynamic languages. 76 IsNotIsNotNyahNyahNyah for the special Playground Edition.

    Of course, you'd need to wrap all of these up in a try/catch/throw NullReferenceException, but that's a small price to pay for completeness.

    77 TheseAreNotTheDroidsYouAreLookingFor

    You guys forgot: Splunge!

  • Gary (unregistered)

    This would have been a lot easier using frames...

    Just sayin'

  • Anonymous (unregistered) in reply to Gary
    Gary:
    This would have been a lot easier using frames...

    Just sayin'

    With all due respect, Gary, I think they should rather hire one of those "C# experts".

  • Jeltz (unregistered) in reply to Paul L
    Paul L:
    VGR:
    No one has mentioned the very first WTF: obtaining a boolean value from a database as a String ... he/she used varchar(5), which cannot be retrieved using ResultSet.getBoolean.
    Nope. He used varchar2(30) for all boolean values.

    Seriously. I'm looking at the schema right now.

    Obviosuly preparing for future i8n support. :) You never know how long words some language may have for YES and NO. Also not trusting the database to contain the right case of YES and NO is nice.

  • let's see (unregistered) in reply to snoofle
    snoofle:
    El Dudarino:
    The real WTF is that they used List instead of ArrayList.
    There's nothing wrong with returning the interface to an object instead of the object itself. It's the one thing in that code that's NOT a wtf!

    Not only there's nothing wrong with it, it is the only sensible thing to do if you want your system to be maintainable and expandable, which are two of the promises made by OO - if you use it correctly, that is ;o)

    Speaking of correct use - there are two more major WTFs:

    • The lazy instantiation is not thread safe.
    • The List is mutable (making the reference private does not solve that), one could simply clear the list from outside.

    Both issues can easily be overcome (the fact aside that this improved implementation would still be stupid boolean-wise!! ;o):

    public final class OurBoolean {
    
        public static final String TRUE = "TRUE";
        public static final String FALSE = "FALSE";
    
        private static final List list;
    
        static {
            List t = new ArrayList();
            t.add(TRUE);
            t.add(FALSE);
            list = Collections.unmodifiableList(t);
        }
    
        public static List getList() {
            return list;
        }
    
        private OurBoolean() {}
    }
    

    This does lazy instantiation implicitely in a thread-safe manner as soon as the class is loaded, coded in the static initializer block which is called exactly once at class loading time. This also allows to declare the reference variable "list" as final (not that this is really necessary, it's private after all, just as a hint to others reading our code ;o)

    The call to the static initializer happens when the class is used for the first time, in this case if someone called OurBoolean.getList(). Only using the constants OurBoolean.FALSE or OurBoolean.TRUE respectively will however not trigger the lazy instantiation.

    Finally (to make it a real singleton), we add the "final" keyword to the class declaration and add a private default constructor - the class only has static members, so there's no point in it being instantiable and inheritable.

    This is the best idiom for implementing the singleton pattern in Java. It is also possible to declare getList() as synchronized, but that imposes a runtime penalty on each call to getList(), not only the first one.

    The call to Collections.unmodifiableList() solves the second issue - the reference returned by getList() will now deny any attempts to add/remove elements or clear the whole list by throwing an exception.

  • Yanman (unregistered)

    What about 1 and 0?

    Or doesn't SQL accept that.

  • Murf (unregistered)

    They probably did this as their DBA decided to store booleans in the database as varchars (hint: the db.utils package?). Many databases don't or didn't support booleans. While I would've gone with a bit instead of a varchar, it's not a huge WTF.

  • (cs) in reply to let's see
    let's see:
    snoofle:
    El Dudarino:
    The real WTF is that they used List instead of ArrayList.
    There's nothing wrong with returning the interface to an object instead of the object itself. It's the one thing in that code that's NOT a wtf!

    Not only there's nothing wrong with it, it is the only sensible thing to do if you want your system to be maintainable and expandable, which are two of the promises made by OO - if you use it correctly, that is ;o)

    Speaking of correct use - there are two more major WTFs:

    • The lazy instantiation is not thread safe.
    • The List is mutable (making the reference private does not solve that), one could simply clear the list from outside.

    Both issues can easily be overcome (the fact aside that this improved implementation would still be stupid boolean-wise!! ;o):

    public final class OurBoolean {
    
        public static final String TRUE = "TRUE";
        public static final String FALSE = "FALSE";
    
        private static final List list;
    
        static {
            List t = new ArrayList();
            t.add(TRUE);
            t.add(FALSE);
            list = Collections.unmodifiableList(t);
        }
    
        public static List getList() {
            return list;
        }
    
        private OurBoolean() {}
    }
    

    This does lazy instantiation implicitely in a thread-safe manner as soon as the class is loaded, coded in the static initializer block which is called exactly once at class loading time. This also allows to declare the reference variable "list" as final (not that this is really necessary, it's private after all, just as a hint to others reading our code ;o)

    The call to the static initializer happens when the class is used for the first time, in this case if someone called OurBoolean.getList(). Only using the constants OurBoolean.FALSE or OurBoolean.TRUE respectively will however not trigger the lazy instantiation.

    Finally (to make it a real singleton), we add the "final" keyword to the class declaration and add a private default constructor - the class only has static members, so there's no point in it being instantiable and inheritable.

    This is the best idiom for implementing the singleton pattern in Java. It is also possible to declare getList() as synchronized, but that imposes a runtime penalty on each call to getList(), not only the first one.

    The call to Collections.unmodifiableList() solves the second issue - the reference returned by getList() will now deny any attempts to add/remove elements or clear the whole list by throwing an exception.

    Wow, you do have a lot of spare time on your hands ...

    This is rather impressive, but you need to check on the class design critiques above. There are many excellent reasons to make this class inheritable (such as NotQuiteOurBoolean, OurI18NBoolean, and my own contributions, OurPossiblyNullBoolean and YoMommaBoolean). Clearly, OurBoolean should reside in a much-used and much-loved library. Making bits of it final would defeat the purpose.

    In fact, I don't think it should be a class at all. I think it should be an interface.

    We need to work on this.

  • Jacksass (unregistered)

    I hate Java. Makes me upchuck a little every time I see it. Bleh! As for ourBoolean, I guess someone learned to do things the long hard stupid way. Java teachers are predominantly useless fecks, too.

  • EH? (unregistered) in reply to kwilliaa

    Why? Oh god, why? Us C programmers survive with 0's for false and (void*)NULL and everything else for true. Makes purfect sense. And back in the old day when people used assembly we just used the zero flag to determine the truethness...

  • Nielsz (unregistered)

    Don't forget the "t" and "f"!

  • Andrey Vul (unregistered) in reply to snoofle
    snoofle:
    Fixed:
    ThePants999:
    It "optimizes for memory usage" by creating a 10-element list to hold boolean values...
    What in the world makes you think that the default allocation of <10> is anywhere near enough to store a boolean value?

    1 TRUE 2 "TRUE", "True", "true" 5 FALSE 6 "FALSE", "False", "false" 9 true 10 false 11 Boolean.TRUE 12 Boolean.FALSE 13 "Y", "Yes, "YES", "y", "yes" 18 "N", "No", "NO", "n", "no" 23 FileNotFound 24 Maybe, MAYBE, maybe 27 Possibly, POSSIBLY, possibly 30 SOMETIMES, Sometimes, sometimes 33 TrueFalse, truefalse, TRUEFALSE, TF, tf 38 VERYTRUE, VeryTrue, verytrue, VT, Vt, vt 44 VERYFALSE, VeryFalse, veryfalse, VF, Vf, vf 50 UNKNOWN, Unknown, unknown, U, u 55 TRYAGAINLATER,TryAgainLater,tryagainlater,TAL,Tal,tal 61 TheFutureIsUnclear 62 SegFault 63 Paula 64 WTF 65 NOTTRUE,NotTrue,nottrue,NT,Nt,nt 71 NOTFALSE,NotFalse,notfalse,NF,Nf,nf

    Thanks to all for corrections/ommissions

    76 NotSegFault, ... 77 NotMaybe, ... 78 NotPossibly, ... 79 NeitherTrueNorFalse, NotTrueFalse, ntnf, ntf, ... ... n NotABoolean, NAB, nab, NaB, ...

    Reminds me of the WTF where the code can go to 14.

  • WTF?!? (unregistered) in reply to Paula Bean

    Why does the internal database representation depend on how the GUI is implemented?

    Please tell us what company you work for and who is your client....

    That way, the rest of us can be sure to turn down positions at your company and your client's.

  • WTF?!? (unregistered) in reply to Paula Bean
    Paula Bean:
    Yes we use this pattern a lot ourselves...

    Its great if your client isnt quite sure how they want the values for TRUE and FALSE represented in the GUI....if they change their minds then its simple to just make a change to the code in one place...

    Over all this is a Brillant Pattern.

    Why does the internal database representation depend on how the GUI is implemented?

    Please tell us what company you work for and who is your client....

    That way, the rest of us can be sure to turn down positions at your company and your client's.

  • SoulReaver (unregistered) in reply to wgh

    Yeah yeah allright, my mistake. I just meant to change the parameters not the uppercase. if 'A' can be null and B can never be null, don't write (A !=null && A.equals(B)) but write (B.equals(A)) just to avoid another not-null-check...

    The toUpperCase method was not the point...

  • FreekV (unregistered)

    Haha, the "file not found" jokes just don't get old. Come one, I thought this site was about smart but dubious hacks. This is just boring.

  • Erycius (unregistered) in reply to snoofle

    you forgot 1 and 0

  • benz (unregistered) in reply to snoofle

    lol @filenotfound

  • MiniTrue (unregistered) in reply to let's see
    let's see:
    This does lazy instantiation implicitely in a thread-safe manner as soon as the class is loaded, coded in the static initializer block which is called exactly once at class loading time. This also allows to declare the reference variable "list" as final (not that this is really necessary, it's private after all, just as a hint to others reading our code ;o)

    The call to the static initializer happens when the class is used for the first time, in this case if someone called OurBoolean.getList(). Only using the constants OurBoolean.FALSE or OurBoolean.TRUE respectively will however not trigger the lazy instantiation.

    Finally (to make it a real singleton), we add the "final" keyword to the class declaration and add a private default constructor - the class only has static members, so there's no point in it being instantiable and inheritable.

    This is the best idiom for implementing the singleton pattern in Java. It is also possible to declare getList() as synchronized, but that imposes a runtime penalty on each call to getList(), not only the first one.

    The call to Collections.unmodifiableList() solves the second issue - the reference returned by getList() will now deny any attempts to add/remove elements or clear the whole list by throwing an exception.

    And this, ladies and gentlemen, is why some projects are never completed... on time, on budget, or at all.

    "Something that is complex and sophisticated is not always the best and reliable. What is simple is better."

    • Mikhail Kalashnikov
  • JimM (unregistered) in reply to Paul L
    Paul L:
    gabba:
    And by calling it OurBoolean, he makes everyone responsible for this gem, not just him.

    Where the result is NULL, it's assumed to be FALSE, except where it's assumed to be TRUE.

    Fantastic! That's the kind of statement I started programming for ;^)

    Mind you, this whole thing is only one step on from soem of the people I did my MSc with, who used to write code like "if (var == true)" and (even better) "if (var != true)". I got bored of pointing out the futility of this eventually...

  • (cs) in reply to Someone You Know
    Someone You Know:
    slavdude:
    [/dating myself]

    You need a girlfriend.

    Got one.

  • (cs) in reply to An apprentice
    An apprentice:
    s.:
    And imagine how extendable that code is!

    Say, you want to port your code to a quantum computer. You just modify the OurBoolean class to return a float in range of [0-1] instead of strings, and you're home!

    Don't forget to initialise your list with all possible floats.

    C|N>k!

  • Theodore (unregistered)

    REAL WTF! There is NO optimisation at all, because in Java equal strings will return very SAME object, so no need caching.

    Things going worse, because there are no protection against multithread access, so in turn it is possible to get TWO list objects (But regarding to what I say above, it is not relevant)

    Captcha: uxor (wtf?)

Leave a comment on “OurBoolean”

Log In or post as a guest

Replying to comment #:

« Return to Article