• (cs) in reply to The Cat
    The Cat:
    MutableBoolean: The unspeakable love-child of Erwin Schrödinger and George Boole. You never really know if it's true or false until you call the accessor method.

    Erwin Schrödinger and Grace Hopper would have been funnier, for biologically obvious reasons. Apologies to anyone to whom the concept of sexual intercourse makes them vomit into their lunch.

  • Flat Hardwood (unregistered) in reply to Matt Westwood
    Matt Westwood:
    The Cat:
    MutableBoolean: The unspeakable love-child of Erwin Schrödinger and George Boole. You never really know if it's true or false until you call the accessor method.

    Erwin Schrödinger and Grace Hopper would have been funnier, for biologically obvious reasons. Apologies to anyone to whom the concept of sexual intercourse between two long-dead people makes them vomit into their lunch.

    The ejection of substance isn't cumming from my mouth... [color=white]...but from my ears[/color=white]

  • Neel (unregistered)

    Obviously, we are not adding 2 numbers, we are just adding funk here. Whats the problem?

  • (cs) in reply to Val
    Val:
    /** *Stops the the following comment from not be made not non-uninvisible */
    Unstopped it from not being made not non-uninvisible for you!
  • (cs) in reply to EvanED
    EvanED:
    hoodaticus:
    Jay:
    hoodaticus:
    Let's say I have a Controller object that manages state, including boolean state, for a graph of objects. Why would I not give objects that depend upon that boolean state a reference to the Controller object instead of farming out to yet another object on the heap that adds nothing of value whatsoever?

    Absolutely true ... IF you have other variables that would go in the object. But what if, for the problem at hand, the only variable you have is a single boolean. You COULD create a custom object just to hold that one boolean. But why? Why not just create a MutableBoolean that you can use in other places where you also have a single boolean?

    Yes, I don't use a MutableBoolean or a MutableInteger or a Mutable-anything-else when what I really want is an object with several variables. That would just be an unnecessary extra step. But it's not at all uncommon to have just one field that I need to manage for the current problem.

    SOMETHING created that MutableBoolean. Why not just store the boolean inside it and pass it as a reference to the subscribers?
    Why don't you store the return value in a field instead of returning it?

    Because it often (even usually) doesn't make sense. That return value doesn't have meaning outside of the context of the call, so it needn't be -- and in fact shouldn't be -- made to persist.

    For instance, take a look at BigInteger; like the boxed types, it is immutable. BigInteger has two functions that do division: BigInteger divide(BigInteger other); BigInteger[] divideAndRemainder(BigInteger other); The second version returns an array where [0] is the quotient and [1] is the remainder.

    I'd argue that the following would have been a not-entirely-unreasonable alternative for this API: BigInteger divide(BigInteger other, MutableBigInteger outRemainder) And even if that's not what you want to present to the client, I think it's reasonable to have as a private function behind the scenes.

    Now, your proposal: don't use a MutableBigInteger, but put a BigInteger field in some other object and have divide set it.

    What object should get it? The one you're calling divide on? So it's going to have a remainderFromTheLastTimeYouCalledDivide field in it? Oh, and now your immutable object isn't, because it has to change that field.

    The one that has the call to divide is in? So there should be an CanHoldTheRemandierOfDivision interface with a setTheRemainderOfDivision() function, and divide should take a CanHoldTheRemaniderOfDivision object?

    There's no good place for that field.

    Finally, an answer that makes sense. Thanks, EvanED!

  • Kraut (unregistered) in reply to josefx
    josefx:
    The MutableBoolean should be obvious for anyone familiar with the java wrapper classes. java.lang.Boolean is not Mutable so MutableBoolean is a good name for boolean wrapper with a public non final value field

    Agee.Probalby there a MutableBoolean passed to some distant class and needs to be updated at a later point while application is run. Actually quite smart.

    So this one is a miss I guess, bound to happen some time too :=)

  • someone (unregistered)

    For some reason I'm feeling a strong urge to share my opinion about these particular WTFs with you. Each and every in this article are making sense to me. I'm not coding that way, but I see the reasons behind such code. Usually the reason is an unanticipated change. Since there is some PHP code, I'd expect something very filthy and utterly pervert, yet you've published a relatively meaningful code.

    Perhaps that's because the average PHP coder wouldn't read this portal. I've had worked with some Indians, Russians, Germans, Pakistanis, and I've quite formed an opinion about their typical code output. The only thing worse than having such co-workers is having such co-workers and trying to deliver a usable and functional product.

    Time management: 10% development, 30% struggling with Notepad++ because they are too stupid to learn how to use an advanced IDE (Eclipse), 25% struggling with SVN because they keep constantly overwriting changes of each other, 10% bug-fixing, 10% bug-fixing of previously applied bug-fixes, 10% bug-fixing of newly introduced bugs during the 2 previous bug-fixing sessions, and 5% looking up every single PHP command before its use at php.net because they are unable to use any proper IDE.

    // I did quit already. Never again will I accept an offer from such companies. And this is a real WTF! :)

  • The Crunger (unregistered) in reply to E. Pesker
    E. Pesker:
    ah- thanks, but I've clearly not given enough context here.

    The main "arguer" is the head of development. He does in fact maintain much of this, and adds new features in much the same style. He just doesn't see the value in clean code- actually doesn't seem to think it's possible.

    Does tend to have a good attitude about it all though. Thinks it's pretty funny when "fixes" cause other bugs and such.

    Quite frustrating, but I do get paid.

    Well, the odds are against you in these sorts of arguments. At least the guy knows how to code his way out of a hat -- there are plenty enough out there who don't. The advice is "pick your battles".

    I'm not even sure which point of this WTF you are arguing (and losing). There are so many.

    • The author of the isLoggingEnabled() is definitely showing a sign of intelligent life, putting up an intelligent facade around a ridiculously denormalized implementation.

    • The use of a run-time comparison for -1 is generally more readable than forcing an outcome using the pre-compiler. Mileage may vary per shop, but I read much more run-time code, and using #if forces a logical gear shift for me, let alone the syntax and indentation breaks.

    • Every now and then "static" macro's like MAX_ATTACHMENT get turned into calls to a global function -- remember errno -- and the more-poorly defined the macro, the more likely. A runtime comparison works better; most compilers are smart enough to recognize a comparison with a constant result.

  • (cs) in reply to The Crunger
    The Crunger:
    * Every now and then "static" macro's like MAX_ATTACHMENT get turned into calls to a global function -- remember errno -- and the more-poorly defined the macro, the more likely. A runtime comparison works better; most compilers are smart enough to recognize a comparison with a constant result.
    Of course, the downside is that after they recognize them, they warn about them... meaning you either have to turn off that warning or filter it out some way.

    I'm not sure that's enough of a reason to prefer the #if, but it is a benefit.

  • (cs)

    The funny part about the mutable boolean is that there is a chain of reasoning behind it that is at once perfectly rational and completely stupid.

  • foxyshadis (unregistered) in reply to Joe
    Joe:
    QJo:
    Arthur de Jong:
    On Solaris 8 (old box hanging around) /bin/true is (this is the whole file):
    #!/usr/bin/sh

    #ident "@(#)true.sh 1.6 93/01/11 SMI" /* SVr4.0 1.4 */

    So I'm afraid no WTF there either.

    TRWTF is that it took them 7 revisions to get to it.

    I'd love to see the "blame" output for it. Can you imagine what bugfixes have gotten us to this point?

    --Joe

    1.1 was probably adding the copyright notice in 1984. The rest were likely adding a new date each time, incrementing the version even though NO non-comment changes were made. Some management is extremely anal about that practice.

  • zld00001 (unregistered) in reply to joe.edwards
  • Spudd86 (unregistered) in reply to Wonk

    Except that's the BSD license... so this is an open source Hello World, that doesn't comply with it's own license since it does not reproduce the license text at run time.

  • Spudd86 (unregistered) in reply to oppeto

    Well, you're free to compile it, you just can't give anyone the class file without violating the terms of the license :P Of course the license terms allow you to modify the source code, so you could fix that problem if you really wanted to give someone a binary from this program.

    All of which is made moot by the fact that the program is probably to short to actually be copyrightable.

  • Paul F (unregistered)

    What I find funny about the #define HEX(A) (0xA) is that it doesn't actually work. The second A is part of the constant hexadecimal number. It's EXACTLY the same as writing:

    #define HEX(A) (10)

Leave a comment on “Not Non-uninvisible, addfunk(), and More”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article