• (cs) in reply to JavaSucks
    JavaSucks:
    Eryn:
    it's so sad to see so many Java bashers on this forum, i wonder where they all come from? You can accomplish something a million different ways, generics have their place, and just remember that J2SE5 incorporated generics from C#
    No, they didn't. Generics in C# are real generics. You can tell the difference between a C# List<int> and a C# List<long>.

    You can't even create a Java List<int>. Instead it becomes a List<Integer> at compile time and then a List at runtime because Java doesn't really support generics.

    If you want to see generics done right, look at C#. If you want to see generics turned into worthless syntactic sugar than can allow you to stick Booleans into a list of Strings simply by disabling warnings, look at Java.

    The Java way of implementing Generics is more efficient - it's a compile time feature that doesn't bloat the resulting byte code. C# uses a C++ approach, where for every type of generic container (List<Foo>, List<Bar>) another class is generated at compile time.

  • JavaSucks (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    The Java way of implementing Generics is more efficient - it's a compile time feature that doesn't bloat the resulting byte code. C# uses a C++ approach, where for every type of generic container (List<Foo>, List<Bar>) another class is generated at compile time.
    There's more to efficiency than memory. Now granted Java is so incredibly bloated that it probably makes sense for Sun to save as much memory as possible.

    But the general rule to optimization is that you can either be memory efficient or time efficient. Either approach is "good" depending on the environment.

    The Java approach is more memory efficient, but not much more memory efficient. You're saving a couple of KB at most.

    The C# approach is more time efficient: it's faster.

    On a modern system, the C# approach is clearly better. It may waste a few KB, but when system memory today is measured in GB, who cares?

    And it guarantees that you can't mix types, even when compiler warnings are disabled.

  • (cs) in reply to KattMan
    KattMan:
    Actually you are partly wrong. Enums are fine having null values and remaining as such and this makes them NOT a boolean.

    Booleans (in most languages) are two valued variables that can have a third state of uninitialized. This state effectively means null. Now if you can not safely assume a null value is actually one of two predefined values you do not have a boolean.

    nwbrown:
    If the value hasn't been initialized, you can't assume it means anything. Just throw a runtime exception because you are in an invalid state and move on with your life.

    Now of course if you just use lower case booleans, Java enforces this for you by requiring them to be initialized before it ever gets used. Upper case Booleans are just intended to be wrappers for those primitives so that they can be used in things that only take Objects such as collection classes.

    KattMan:
    Actually you are wrong. If you are working with a true boolean state and you see one that is not initialized then you can and should the default safe state and continue. If you can not assume a safe state you are not working with a boolean.

    I gave two examples of valid booleans that you can assume a state with, now let's think of one that many people incorrectly assume they can use a boolean for, gender. If you assume 1 is male and 0 is female and you see an uninitialized gender variable, what is the safe decision? There is none. This is a third state and therefore not a boolean which is defined as two state. So you now have Male Female and unspecified.

    There's a conflict here, I think. If you're designing a system, you're mainly looking at semantics and not implementation. The semantics of "boolean" are about as simple as they get. On, off. True, false. Even as an implementer, your brain is likely to be hard-wired to think this way. There are precious few computer languages that do not make extensive use of boolean algebra, and I'm hard pressed to think of a construct in any of them that evaluates a boolean expression as "null."

    On the other hand, if everything is an Object (unless it doesn't really exist, duh), then the uninitialised state of null rears its ugly head again. This is an unfortunate consequence of the design of the language. Nothing wrong with that; all languages have compromises built into their design. However, I would argue that to have a primitive type of "boolean" that actually is a boolean, and a class type of "Boolean" that is no such thing, is simply a lie.

    I tend to the KattMan side of this argument. Exuberant chucking of exceptions for something trivial such as a non-initialised boolean that, in fact, indicates a design flaw is not the way to go. (And yes, I'm aware that KattMan argues that null, defaulting to the "assumed" state, is valid "in most languages." I'd go further and claim that you cannot "assume" the state of a true boolean, and that the compiler should barf, or at least warn. But that would only work with strongly typed languages, indeed with compiled languages -- inferred typing would be fine -- and is, I suppose, my personal preference. There is no such thing as "finished state." There is only "state.")

    Don't even get me started on Perl's wonderful "auto-vivification."

  • knock it off... (unregistered) in reply to Knitpik
    Knitpik:
    The real WTF is using Java to do anything at all. It's a sh|t language.

    Wow.

    I'm truly impressed by your deeply profound statement. Would you care to elaborate what you do find reproachable about certain languages and/or share your invaluable notion of what language you do deem worthy of your highly esteemed attention...

    ...or are you just trolling (and most likely hacking yourself along in VB and thinking of it as "programming")?

  • (cs) in reply to knock it off...
    knock it off...:
    Knitpik:
    The real WTF is using Java to do anything at all. It's a sh|t language.

    Wow.

    I'm truly impressed by your deeply profound statement. Would you care to elaborate what you do find reproachable about certain languages and/or share your invaluable notion of what language you do deem worthy of your highly esteemed attention...

    ...or are you just trolling (and most likely hacking yourself along in VB and thinking of it as "programming")?

    Troll on ... or register.
  • bull (unregistered)

    Let's see what we have here: -singleton -factory -It seems like the factory "pre-cache" its products. Since it's have a property named YES. This guy really know how to optimize -A product class that can represent a YES or NO value that is comparable to a string . Quite good for dynamic typing -An interface (IYesNo) to access all these stuffs ... A new world of boolean This is a revolution in programming. Wtf man, why is it a wtf?

    Wait a minute, string parsing? Maybe he is trying to deal with "yes" and "no" in different language? Still wtf though.

    Captcha: gotcha . No, you didn't

  • Stuart (unregistered) in reply to gabba

    Geekwad is quite right. His/her original point was

    What if you don't want data, but a model? What if the model needs to support subscribers who might be in another process written in another language running on a different server? What if you are talking to your subscribers with a lossy channel (for instance, the ultimate consumer might even be a human, who are inherently lossy) and need to keep track of your client's states as well as your own?

    These are standard requirements in the big world beyond the provinces. Most of the comments on this item are just haystraw giggles.

  • VirGin (unregistered)

    Unfortunately, it isn't just new developers that do things like that. I've seen code that was written by experienced folks that do similarly silly things.

    A simple example... image a C++ class that has two data members and one member function. It doesn't inherit from anything and nothing inherits from it. The member function sets or returns the value of the private member variable based on the value of the public member variable.

    Since the class doesn't actually use any C++ capabilities (inheritance, polymorphism, etc), a simple struct would have been much more appropriate. The code base I am working with is filled with such ... things.

    -V-

  • Hognoxious (unregistered) in reply to Kuli
    Kuli:
    I suggest that s.o. created an YesNo-Entity in the (UML?) model
    If so that confirms my suspicion that anything remotely connected with UMP is a pile of poo.
  • lagerdalek (unregistered)

    too YesNoFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase()), too YesNoFactory.getFactoryInstance().YES.getDescription().equals(array[0].toUpperCase()).

Leave a comment on “Taking a Good Thing Too Far”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article