• (cs) in reply to Nagesh
    Nagesh:
    Enum type in Java is a class by definition, but many programmers tend to forget this, because they rather relate it to "a list of allowed values" as in some other languages. It's more than that.

    So, to avoid those switch statements it might be reasonable to put some code and additional methods in the enum class. There's almost never a need to create a separate "enum-like real class".

    So, we have a post without Engrish. You are finally exposed for the faker we always knew you were.
  • (cs) in reply to Sock Puppet 5
    Sock Puppet 5:
    Nagesh:
    Enum type in Java is a class by definition, but many programmers tend to forget this, because they rather relate it to "a list of allowed values" as in some other languages. It's more than that.

    So, to avoid those switch statements it might be reasonable to put some code and additional methods in the enum class. There's almost never a need to create a separate "enum-like real class".

    So, we have a post without Engrish. You are finally exposed for the faker we always knew you were.

    What a true Nagesh speaks is Hinglish, not Engrish.

    When we get a visit from Haruki, we'll see some Engrish.

    On the other hand, it's possible that he's a fakir.

  • radarbob (unregistered) in reply to Quango

    this would be true if we were checking against absolute values, or the order of the enum members was relevant.

  • (cs) in reply to Sock Puppet 5
    Sock Puppet 5:
    Nagesh:
    Enum type in Java is a class by definition, but many programmers tend to forget this, because they rather relate it to "a list of allowed values" as in some other languages. It's more than that.

    So, to avoid those switch statements it might be reasonable to put some code and additional methods in the enum class. There's almost never a need to create a separate "enum-like real class".

    So, we have a post without Engrish. You are finally exposed for the faker we always knew you were.

    strait copy paste, you idiot!

  • Dirk (unregistered)

    This comment shouldn't never happen.

  • Jon Haugsand (unregistered) in reply to QJo
    QJo:
    In such cases I have been known, so as to ensure backward compatibility, to implement a "dbValue()" to return the specific number that is stored in the database to identify this enum.

    What you do is create the enum with a constructor containing all the ancillary information: database value, UI-friendly description, etc. All the tedious infrastructure associated with that enum can also be programmed into it and the interface can then be as clean as you like.

    Oh, and sorting on the enum is as simple as being determined by the order in which they are declared, but there's nothing wrong with writing as many comparators as you like, and even define extra sort fields if you've got a really challenging set of requirements.

    But it should never be necessary to use the ordinal().

    Storing enums in databases is asking for trouble. You can never extend your enum without upgrading all applications using this db table and row. (Unless, of course, there is just one application accessing this table.) At my place, we now use some kind of "safe enum" which accept any string for deserialization. (Yes, I know, this isn't an enum.) When an unknown string is encountered, we just log a warning and go further as nothing happened.

    /J

  • (cs)

    That reminds me, I once wrote a library that has classes that kinda work like enums, but can be instantiated based on external values, like those in a database. But I forgot how it works, and I doubt I ever actually used it.

  • Chuck Lester (unregistered) in reply to The poop of DOOM
    The poop of DOOM:
    Jim Fell:
    This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.
    So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

    I personally wouldn't say that, BUT, the more you know, the better you would program. Do it is not a matter of saying "I don't want to know this" or "I am not supposed to know this", but instead "I know a lot about the internals, that makes me even better programmer, that makes the difference sometimes"

  • Rajendra Kumar (unregistered) in reply to Nagesh
    Nagesh:
    Sock Puppet 5:
    Nagesh:
    Enum type in Java is a class by definition, but many programmers tend to forget this, because they rather relate it to "a list of allowed values" as in some other languages. It's more than that.

    So, to avoid those switch statements it might be reasonable to put some code and additional methods in the enum class. There's almost never a need to create a separate "enum-like real class".

    So, we have a post without Engrish. You are finally exposed for the faker we always knew you were.

    strait copy paste, you idiot!

    Thus proving Nagesh really is an Indian coder.

  • nagesh (unregistered) in reply to Rajendra Kumar
    Rajendra Kumar:
    Nagesh:
    Sock Puppet 5:
    Nagesh:
    Enum type in Java is a class by definition, but many programmers tend to forget this, because they rather relate it to "a list of allowed values" as in some other languages. It's more than that.

    So, to avoid those switch statements it might be reasonable to put some code and additional methods in the enum class. There's almost never a need to create a separate "enum-like real class".

    So, we have a post without Engrish. You are finally exposed for the faker we always knew you were.

    strait copy paste, you idiot!

    Thus proving Nagesh really is an Indian coder.

    trust only copy-paste everything else is waist.

  • Pyrexkidd (unregistered) in reply to The poop of DOOM
    The poop of DOOM:
    Jim Fell:
    This is a perfect example of why so many applications written in Java (and other high-level programming languages) are terribly inefficient. Most developers who have learned and written only in Java (or C#, etc.) don't have a basic understanding of what actually happens when their code is run. All programmers, regardless of the language they use, need to be aware of what the processor is doing when it executes an 'if' statement, or a 'switch', or when a function is called, etc.
    So you're saying each programmer needs to mentally break down all control structures to LABEL and GOTO statements? Or did you mean to push it further, down to ASM level? Or yet further, to the electrical pulses running through the machine?

    Yes, each programmer needs to break down the code into machine language in their head and then simulate the electrical pulses in their brain.

    You mean... everyone doesn't do this?

  • jverd (unregistered) in reply to Pyrexkidd
    Pyrexkidd:
    Yes, each programmer needs to break down the code into machine language in their head and then simulate the electrical pulses in their brain.

    You mean... everyone doesn't do this?

    "Real programmers set the universal constants at the start such that the universe evolves to contain the disk with the data they want." (http://xkcd.com/378/)

  • Agnostic (unregistered) in reply to The poop of DOOM
    The poop of DOOM:
    So it's more efficient to write shitty code in a low-level language and leave memory leaks and such in due to no garbage collection
    Garbage collection is neither the panacea you think it is, nor a feature of all high-level languages.

    Garbage collection is simply one way of dealing with the tricky problem of memory management. It doesn't always work, and is very bad in some circumstances.

    • For example, an application that requires consistent response times can't be written under a GC system, as there is no way of knowing when (or if!) the GC will decide to use cycles to clean up.
    • It's actually quite easy for a Java program to completely run out of memory and the programmer can't do anything about it, as there is no way of forcing the GC to run.

    There are many other ways, for example RAII, reference counting etc.

    Java forces you to use a GC to the exclusion of all other possible methods, which is probably part of the reason why a lot of people don't like it.

    Dumb pointers as in C require the programmer to handle memory management themselves. In a lot of cases this isn't actually very difficult - it only gets hard when the same piece of data has more than one conceptual 'owner'. It is however quite easy to accidentally lose something like this.

    Incidentally, it's practically certain that the program you were complaining about was written in C - which is not a low-level language.

  • (cs)

    Yet another case of Stringly-Typed programming.

    How to do it : convert anything you access to string, then work your way from there.

    Why do it : types are such a hassle. Human-readable is so much better, besides it stops the compiler from complaining.

    Oh, and bonus points for the useless if/else/return.

  • Neil (unregistered)
    ("" + x)
    doesn't use a StringBuffer, of course.
  • Anonymous Guy (unregistered)

    why even bother with the method and not just call ordinal directly...?

  • snapsnapsnap (unregistered) in reply to Anonymous Guy

    You cannot use ordinal because:

    Returns the ordinal of this enumeration constant (its position in its enum declaration, where the initial constant is assigned an ordinal of zero). Most programmers will have no use for this method. It is designed for use by sophisticated enum-based data structures, such as EnumSet and EnumMap.

    You should instead create enum values with a (private) constructor that takes a number during declaration, and return that with a getter. This way, the returned value is clear, and you can easily add enum values before, after etc. Or, if you don't like keeping that in line with the code using the int, try a hash table enum -> int.

  • Reow (unregistered)

    Unsure if Java Enums are the same as .Net Enums, but .Net Enums are indeed very bad news in all but a few very trivial cases. The primary issue is their lack of ability to be bound to the database, hence lack of flexibility. I'm not saying there's a better fluent approach, just that they do in fact add no real value to an enterprise application.

  • Lluis (unregistered) in reply to Nagesh

    If you must persist the status somewhere (usually in a database) you need an integer or a string. The ordinal attribute makes perfect sense in this case. 99% of the enums in our project work this way, and we don't have such horrid implementation.

Leave a comment on “Bad News Enum”

Log In or post as a guest

Replying to comment #:

« Return to Article