• TheCPUWizard (unregistered)

    Possible that this was intended to be a proper OO pattern (instantiate objects that have the behavior desired rather than run time checking of conditions scattered in the code) that had gone horribly wrong?

  • Balu (unregistered) in reply to TheCPUWizard

    How can you still try to find excuses for something like this?

  • DocMonster (unregistered)

    This a little extreme, but I've seen patterns like this done right and it does help. This is just stupid though.

  • Davidis (unregistered)

    Looks like a person told to use OO who did not understand what it meant.

  • (nodebb)

    A clever (or "clever") implementation of nullable booleans.

    This would explain why they use the instanceof operator instead of an IsTrue method.

  • Ron Fox (google)

    It's not really enterprisey. These classes need to be serializable and their instances loaded from an XML configuration file to even get close.

  • Jester (unregistered)

    "The worst thing Java ever did was force class and package structures to mirror the filesystem. WHY WOULD YOU DO THIS?"

    So I can easily locate the class that contains code that is wrong without doing a global search for it every time. And then when it turns out the offending code is in another class I don't have to look for that either.

  • WTF (unregistered)

    Holy crap! Somebody got their panties in a bunch about something....

  • operagost (unregistered)

    The Shortest Joke in the World

    Blakeyrat.

  • Foo AKA Fooo (unregistered)

    What a great joke! I literally LOLed ... when scrolling through it.

  • Foo AKA Fooo (unregistered) in reply to Jester

    Global searches are useful for many things (such as searching for a specific message to find where it comes from, or finding where some value is used etc.). If a global search is a problem, you're doing it wrong. Try adding a meg or two of RAM so it will fit in cache.

  • Blakeyrat (unregistered)

    This is Oracle's fault. When they would have used C#, this wouldn't have happened. But it's open source, so what do you expect?

  • (nodebb)
    Think of the extensibility! Think of the readability!

    Think of the WTFery!!

  • (nodebb) in reply to Blakeyrat

    WTF does that mean? It's not Oracle's fault that when you use their programming language you're an asshole who doesn't know WTF he's doing. Sorry, Blakeyrat, if you did this, it would be YOUR fault -- not Oracle's -- and it wouldn't matter if it was Java, C#, C++, Ada, or anything else because, clearly, you don't understand how to use these tools.

  • welp (unregistered)

    The ravenous Saar-Chasm claims yet another victim.

  • asr (unregistered)

    have anyone heard of bit fields?

  • Developer Dude (unregistered)

    Paid by line of code.

    That would be a generous assumption.

    I would rather be thought evil than stupid - which (stupidity and/or ignorance) is probably the real cause for code like this.

    I made this comment to my boss a while back when remarking on our codebase (which is similar, but worse, WTFery) and he looked at me like I was evil. At least he didn't think I was stupid.

    Kill all humans and bite my shiny metal ass - I AM A ROBOT!

  • Herby (unregistered) in reply to Developer Dude

    Paid by line length of code variables.

    FTFY

  • Making it up (unregistered) in reply to Blakeyrat

    You're not the real Blakeyrat, you're far too dumb. You haven't fooled anybody.

  • Making it up (unregistered)

    This is a poor implementation of the type-safe enumeration pattern. Java supports it natively. If you must do this, use the native enum type. I'm an enterprise Java programmer but I prefer the boolean.

    Java doesn't require every class to be in its own file. The first class in the file must match the name of the file. Any following classes in the file can be called whatever they want, but they are all going to be in the same package. But if you do this on my project, you're fired. I haven't yet seen a decent argument for allowing file names and class names to differ, let alone stuffing more than one class in a file.

    I see a lot of hate for Java here and there but most of it is irrational like "class names must match file names WTF whargarrbl!". Very little of the hate actually hits on valid criticisms of the language and even when they do they usually miss the context of the original decisions.

  • (nodebb) in reply to Making it up
    I see a lot of hate for Java here and there but most of it is irrational like "class names must match file names WTF whargarrbl!". Very little of the hate actually hits on valid criticisms of the language and even when they do they usually miss the context of the original decisions.

    It has been my experience that those who hate Java don't understand it. Many of the people I have met who say Java sucks write code like this in other languages. I guess it's bad that Java adheres to its own rules and other languages allow you to write whatever you want?

  • (nodebb) in reply to Making it up

    "Java doesn't require every class to be in its own file."

    What Remy said was "one public class per file" which is entirely correct. The rest of the classes can be called whatever and, yes, they will be in the same package, but they will not be public.

  • Erufael (unregistered) in reply to BobbyTables

    Actually Remy never mentioned the word public. He only said that each class must be in its own file. Which is incorrect.

  • (nodebb) in reply to Erufael

    Let's see:

    "WHY WOULD YOU DO THIS? Why would you only allow one public class per file?"

    I can definitely see the word "public" in there. Yep, it definitely sounds like, and I quote, "one public class per file". Which most assuredly seems like exactly the same quote I used previously.

  • Roflcopter (unregistered) in reply to Davidis

    "Looks like a person told to use OO who did not understand what it meant."

    Nope, they got it entirely right. Imagine if you implemented toString() on those classes, it'd be using polymorphism perfectly. Implementing Enum or Boolean the way Java does is simply not OO.

    What's broken here is the fact that OO falls apart with something as simple as representing 'true' and 'false.' You can argue, "oh, but Java provides a perfectly good Boolean class," but it's not perfectly good. It's not OO, it's not extensible, you can't restrict or extend it, etc., so none of the features of OO are actually available. And they have to be turned off for builtin types because you couldn't write a remotely stable program with them on. And when they're on, it's absurdly hard to do things like compare two values for equality:

    "So it seems we are stuck. Is there a sane way to redefine equality on several levels of the class hierarchy while keeping its contract? In fact, there is such a way, but it requires one more method to redefine together with equals and hashCode. The idea is that as soon as a class redefines equals (and hashCode), it should also explicitly state that objects of this class are never equal to objects of some superclass that implement a different equality method. This is achieved by adding a method canEqual to every class that redefines equals."

    Source: http://www.artima.com/lejava/articles/equality.html

    TRWTF is that OO is broken at the most fundamental level.

  • Erufael (unregistered) in reply to BobbyTables

    Psh you never said you meant from the HTML comments, which I never ever check.

  • (nodebb) in reply to Erufael

    It's still content written by Remy. It is, thus, stuff that Remy said. You chose to ignore that and then complained that "it's not something Remy said".

    I don't even understand "I don't even read stuff" defence. You chose to ignore it. It's like saying "Oh, it's from the second paragraph - I never read that". I don't even see "but it's hard to read the comments" as a valid defence: https://greasyfork.org/en/scripts/search?q=dailywtf

    It's not like these haven't existed for YEARS.

  • roboprog (unregistered) in reply to BobbyTables

    You can also put in public inner classes, which works well if they are actually related to / support the outer class (but seem silly otherwise). E.g. Map.Entry.

  • roboprog (unregistered) in reply to Bananafish

    Let's just say that Java has room for improvement, and much of the culture around it fetishizes "WET" code.

    E.g. - I would really like something like a Pascal type alias clause for things like repeated "generics" descriptions for variable declarations. E.g. - FooCache = Map<String,Foo> without having to make a class and then fight with "? extends" and such, or a cleaner lambda syntax vs "BiFunction <ParmA, ParmB, RetVal>" (also repeated ad nauseum in some cases).

  • eklerks (unregistered)

    I actually can see some reason in this. The programmer tried to restrict the domain his truth values could operate in (a boolean from a door sensor doesn't make sense in the context of a file browser) or extend its semantics. (add a Unknown value).

  • Dreadwolf (unregistered)

    Why one public class per file? Because Java is a sane language for intelligent people.

  • Dieter H (unregistered)

    obviously not a problem in implementation, but design. Why in the world would you set a constant and assign it with "true", then run a conditional over it? The conditional is completely superfluous. Either it is a variable, or it's not variable and all the code in the example could be deleted.

  • Me (unregistered)

    I just read this with a jawdrop all the way through. Not even joking or exaggerating.

  • Vida (unregistered)
    Comment held for moderation.
  • Vida (unregistered)
    Comment held for moderation.

Leave a comment on “Constantly Extended”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article