The Daily WTF: Curious Perversions in Information Technology

2011-11-14 Reply Admin

Nagesh:
Well you are wrong there budy.

Bugger off, troll.

2011-11-14 Reply Admin

jverd:
Nagesh:
Well you are wrong there budy.

Bugger off, troll.

String str = "a" + "b" + "c";

This is not being transleted to StrangBufer calls.

2011-11-14 Reply Admin

Baboon:
The real WTF is using the ordinal method itself, it provides very little value IMO

The only reason I can think of is when the ordering of the enum entries is meaningful. In such a case, you might use it to sort values for a drop-down box, or to compare whether one value is logically before or after another...

Weps · 2011-11-14 Reply Admin

Architect:
article:
Just for reference, how could be rewritten it in a single line:
public Integer checkStatus(Status status){
    return status.ordinal(); 
}</div></BLOCKQUOTE>You see? In Java even a single line takes three lines!!</div></BLOCKQUOTE>
It should just have been

status.ordinal();

Besides, what does it check?

2011-11-14 Reply Admin

jverd:
The problem comes in constructs like
String s = "";
while (...) {
  s += something;
}
Which cannot be expanded to a fixed number of append() calls on a single SB object, but instead requires creating at least an SB and a String for every iteration.

Not necessarily. A compiler needs to be smarter to translate the loop version into StringBuffer calls, but if the string is never read within the loop, it's a reasonable optimisation to make. I don't think Java 6 was smart enough to do it, but 7 might be...

2011-11-14 Reply Admin

Simon:
jverd:
The problem comes in constructs like
String s = "";
while (...) {
  s += something;
}
Which cannot be expanded to a fixed number of append() calls on a single SB object, but instead requires creating at least an SB and a String for every iteration.
Not necessarily. A compiler needs to be smarter to translate the loop version into StringBuffer calls, but if the string is never read within the loop, it's a reasonable optimisation to make. I don't think Java 6 was smart enough to do it, but 7 might be...

I doubt the javac compiler will, but if you mean hotspot, then sure, I can see it in some cases unrolling the loop. But in the general case (such as reading until end of stream), it can't.

My point was primarily about those kinds of loops being the only case where we (might) need to worry about explicitly using SB, as opposed to simple s = a + b + c + ... cases, which people often erroneously think lead to Java's "inefficient" string concatenation.

2011-11-14 Reply Admin

jverd:
Simon:
jverd:
The problem comes in constructs like
String s = "";
while (...) {
  s += something;
}
Which cannot be expanded to a fixed number of append() calls on a single SB object, but instead requires creating at least an SB and a String for every iteration.
Not necessarily. A compiler needs to be smarter to translate the loop version into StringBuffer calls, but if the string is never read within the loop, it's a reasonable optimisation to make. I don't think Java 6 was smart enough to do it, but 7 might be...
I doubt the javac compiler will, but if you mean hotspot, then sure, I can see it in some cases unrolling the loop. But in the general case (such as reading until end of stream), it can't.

My point was primarily about those kinds of loops being the only case where we (might) need to worry about explicitly using SB, as opposed to simple s = a + b + c + ... cases, which people often erroneously think lead to Java's "inefficient" string concatenation.

Oh, I guess I missed part of your point. As to the bit about the String not being read, I don't think that matters. The SB approach is the implementation that the current Oracle compilers happen to use, as would most compilers I assume, but it's not required. So I don't think that an optimizer can assume there are no side effects that need to be preserved.

We're far into an area where I don't really have any expertise though, so I could be wrong about this part of it.

2011-11-14 Reply Admin

    if(checkedStatus==null){
        return null; //Shouldn't never happen
    }

During code reviews, somebody I know likes to replace "should never happen" comments with:

System.exit(-1);

When the original coder complains, he simply points out that it should never happen, so the System.exit line shouldn't be a problem, right?

2011-11-14 Reply Admin

jverd:
Oh, I guess I missed part of your point. As to the bit about the String not being read, I don't think that matters. The SB approach is the implementation that the current Oracle compilers happen to use, as would most compilers I assume, but it's not required. So I don't think that an optimizer can assume there are no side effects that need to be preserved.

I think you've still missed the point of the post - we're not talking about runtime optimization at all. What I'm saying is that the optimizations performed by the compiler can be extended to cover the loop case. That is, the example you give above should result in identical bytecode to:

StringBuilder sb = new StringBuilder("");
while (...) {
  sb.append(something);
}
String s = sb.toString();

Now, I'm not aware that any existing compiler takes the optimizations this far. But there's no reason I can see why that couldn't change in future, if someone thought it would be worth it.

2011-11-14 Reply Admin

Simon:
jverd:
Oh, I guess I missed part of your point. As to the bit about the String not being read, I don't think that matters. The SB approach is the implementation that the current Oracle compilers happen to use, as would most compilers I assume, but it's not required. So I don't think that an optimizer can assume there are no side effects that need to be preserved.

I think you've still missed the point of the post - we're not talking about runtime optimization at all. What I'm saying is that the optimizations performed by the compiler can be extended to cover the loop case. That is, the example you give above should result in identical bytecode to:
StringBuilder sb = new StringBuilder("");
while (...) {
  sb.append(something);
}
String s = sb.toString();
Now, I'm not aware that any existing compiler takes the optimizations this far. But there's no reason I can see why that couldn't change in future, if someone thought it would be worth it.

Okay, so, yes, IF javac starts doing optimizations it has typically left for hotspot, and IF it can confirm that the String is never read inside the loop, then, yes, it could do that optimization, skipping the unneeded creation of intermediate Strings.

2011-11-14 Reply Admin

Simon:
jverd:
Oh, I guess I missed part of your point. As to the bit about the String not being read, I don't think that matters. The SB approach is the implementation that the current Oracle compilers happen to use, as would most compilers I assume, but it's not required. So I don't think that an optimizer can assume there are no side effects that need to be preserved.

I think you've still missed the point of the post - we're not talking about runtime optimization at all. What I'm saying is that the optimizations performed by the compiler can be extended to cover the loop case. That is, the example you give above should result in identical bytecode to:
StringBuilder sb = new StringBuilder("");
while (...) {
  sb.append(something);
}
String s = sb.toString();
Now, I'm not aware that any existing compiler takes the optimizations this far. But there's no reason I can see why that couldn't change in future, if someone thought it would be worth it.

Okay, so, yes, IF javac starts doing optimizations it has typically left for hotspot, and IF it can confirm that the String is never read inside the loop, then, yes, it could do that optimization, skipping the unneeded creation of intermediate Strings.

2011-11-14 Reply Admin

Although, again, this is an aside from my original post in this subthread, the point of which was that we don't need to worry about using SB outside of this situation.

2011-11-14 Reply Admin

Replacement:
    if(checkedStatus==null){
        return null; //Shouldn't never happen
    }
During code reviews, somebody I know likes to replace "should never happen" comments with:
System.exit(-1);
When the original coder complains, he simply points out that it should never happen, so the System.exit line shouldn't be a problem, right?

I actually have a ShouldNeverReachThisPointException (a RuntimeException) which I use for that kind of situation. Mostly it's there for cases where it really can't reach that point but the compiler isn't smart enough to recognise it - keeps the compiler happy, and serves as clear documentation...

2011-11-14 Reply Admin

jverd:
Okay, so, yes, IF javac starts doing optimizations it has typically left for hotspot, and IF it can confirm that the String is never read inside the loop, then, yes, it could do that optimization, skipping the unneeded creation of intermediate Strings.

Confirming it's never read shouldn't be too hard. Within the loop, the value must never be assigned to another string or passed as a parameter to a method call, and none of the string's methods may be called. That'd cover the basic cases, but you could go a bit further, depending on how much complexity you want to add to the compiler...

Nagesh · 2011-11-14 Reply Admin

jverd:
Nagesh:
Well you are wrong there budy.

Bugger off, troll.

Troll tera baap!

2011-11-14 Reply Admin

Simon:
jverd:
Okay, so, yes, IF javac starts doing optimizations it has typically left for hotspot, and IF it can confirm that the String is never read inside the loop, then, yes, it could do that optimization, skipping the unneeded creation of intermediate Strings.

Confirming it's never read shouldn't be too hard.

Hard, no. A significant deviation from the approach for the last, what, 8-10 years, of saving the optimization for the runtime, yes. Not that it couldn't be done, just that it would be a philosophical shift.

2011-11-14 Reply Admin

Simon:
Replacement:
    if(checkedStatus==null){
        return null; //Shouldn't never happen
    }
During code reviews, somebody I know likes to replace "should never happen" comments with:
System.exit(-1);
When the original coder complains, he simply points out that it should never happen, so the System.exit line shouldn't be a problem, right?
I actually have a ShouldNeverReachThisPointException (a RuntimeException) which I use for that kind of situation. Mostly it's there for cases where it really can't reach that point but the compiler isn't smart enough to recognise it - keeps the compiler happy, and serves as clear documentation...

I often just use AssertionError for this. Even though it's an Error, not a RuntimeException, It's purpose fits the bill.

2011-11-14 Reply Admin

Nagesh:
Totally agree. In most cases, the true integer value of an enum should not be of any relevance (the major exception being storing to a database).

... or sending it across the network to another computer... or saving it to a file, or loading it from a file, or handing it off to another process via shared memory or pipe or whatnot.

Basically any time you are handing the value off to some piece of code that wasn't guaranteed to be compiled at the same time as the current code, then the underlying value becomes important.

2011-11-14 Reply Admin

jverd:
I often just use AssertionError for this. Even though it's an Error, not a RuntimeException, It's purpose fits the bill.

Yes, I suppose that would be the most appropriate choice... and being an Error, it has the benefit of not being caught by the random-monkey coding that considers "catch (Exception e){}" blocks to be an appropriate form of error handling.

Doesn't do anything about "catch (Throwable t){}" blocks, of course. But frankly, doing that without good reason should be a sacking offense...

Iago · 2011-11-14 Reply Admin

Jeremy Friesner:
Nagesh:
Totally agree. In most cases, the true integer value of an enum should not be of any relevance (the major exception being storing to a database).

... or sending it across the network to another computer... or saving it to a file, or loading it from a file, or handing it off to another process via shared memory or pipe or whatnot.

Basically any time you are handing the value off to some piece of code that wasn't guaranteed to be compiled at the same time as the current code, then the underlying value becomes important.

Yeah, if you're a terrible software engineer who loves being called out in the middle of the night to fix mysterious crashes. "Some piece of code that wasn't guaranteed to be compiled at the same time as the current code" isn't guaranteed to have the same ordinal values!

If you need to serialize your enums, you should be assigning an explicit value to each member that is documented to require stability, not relying on the implicit ordinal that someone else might change without realizing it could ever break anything.

Pretty much the only sound use I can think of for Enum.ordinal() is in the implementation of java.util.EnumSet and java.util.EnumMap. And your JRE developers already wrote those for you.

Scarlet Manuka · 2011-11-14 Reply Admin

Iceman:
Just for reference, how could be rewritten it in a single line:
public Integer checkStatus(Status status){ return status.ordinal(); }
Of course, until someone calls the function with a null argument. Hello, NPE.

This replicates the NPE that the original function would throw at String statusStr=status.name();. So it's still maintaining compatibility.

2011-11-15 Reply Admin

[image]

2011-11-15 Reply Admin

TRWTF is Java, as always. Mwahaha

2011-11-15 Reply Admin

+9:
TRWTF is Java, as always. Mwahaha

How terribly original. That never gets old and is not the least bit obvious or pathetic or unfunny. I hope every single wtf that even mentions Java, or where any of the people involved have ever heard of Java, or have drunk a cup of coffee, makes the hilarious observation that "TRWTF is Java", as this shows a level of insight and sophistication that can do naught but elevate the value of this site, propelling its humor and educational value to the stratosphere.

Thank you so much, my friend. We all owe you an enormous debt of gratitude. And, though it be rude of me in the extreme to dare ask more of you, might I please entreat you to come to my house every morning and wake me up be screaming in my ear that "TRWTF is Java"? Being reminded of that perfectly correct, perfectly valuable, always relevant, never trite, and forever inspirational bit of wisdom is the best way I can imagine to start my day, short of feeding my nuts into a meat grinder while squirting boiling dog vomit up my nose.

2011-11-15 Reply Admin

So, after reading through all the comments I fail to understand why enum would have an implicit conversion to integer. Surely the only valid comparison is to the enumerated type values (how that is done across compilation units would be an implementation detail for the javac). Since this is so important, I say TRWTF is the Java language reference, and the thousands of shitty books which show anything other than comparison to an enum'd value. Furthermore, while I do understand the need for a ToString member, the description of that function should contain a huge warning that the string representation should not be used for comparing enums.

QJo · 2011-11-15 Reply Admin

jverd:
Simon:
jverd:
Oh, I guess I missed part of your point. As to the bit about the String not being read, I don't think that matters. The SB approach is the implementation that the current Oracle compilers happen to use, as would most compilers I assume, but it's not required. So I don't think that an optimizer can assume there are no side effects that need to be preserved.

I think you've still missed the point of the post - we're not talking about runtime optimization at all. What I'm saying is that the optimizations performed by the compiler can be extended to cover the loop case. That is, the example you give above should result in identical bytecode to:
StringBuilder sb = new StringBuilder("");
while (...) {
  sb.append(something);
}
String s = sb.toString();
Now, I'm not aware that any existing compiler takes the optimizations this far. But there's no reason I can see why that couldn't change in future, if someone thought it would be worth it.
Okay, so, yes, IF javac starts doing optimizations it has typically left for hotspot, and IF it can confirm that the String is never read inside the loop, then, yes, it could do that optimization, skipping the unneeded creation of intermediate Strings.

Apart from idleness, ignorance and foolish childish arrogance, is there any reason not to program such a loop like taht in the first place?

QJo · 2011-11-15 Reply Admin

Iago:
Jeremy Friesner:
Nagesh:
Totally agree. In most cases, the true integer value of an enum should not be of any relevance (the major exception being storing to a database).

... or sending it across the network to another computer... or saving it to a file, or loading it from a file, or handing it off to another process via shared memory or pipe or whatnot.

Basically any time you are handing the value off to some piece of code that wasn't guaranteed to be compiled at the same time as the current code, then the underlying value becomes important.
Yeah, if you're a terrible software engineer who loves being called out in the middle of the night to fix mysterious crashes. "Some piece of code that wasn't guaranteed to be compiled at the same time as the current code" isn't guaranteed to have the same ordinal values!

If you need to serialize your enums, you should be assigning an explicit value to each member that is documented to require stability, not relying on the implicit ordinal that someone else might change without realizing it could ever break anything.

Pretty much the only sound use I can think of for Enum.ordinal() is in the implementation of java.util.EnumSet and java.util.EnumMap. And your JRE developers already wrote those for you.

+1 Was about to make a similar comment.

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().

2011-11-15 Reply Admin

QJo:
Apart from idleness, ignorance and foolish childish arrogance, is there any reason not to program such a loop like taht in the first place?

You mean why would one not use the preferred append() approach, and instead fall back on the += approach? Sometimes if I know the sizes and iteration count will be small, especially for things like developer tools and one-offs, I'll be lazy and go with the +=. But otherwise, no, there's no good reason to use += over append().

But I don't think anybody was advocating += anyway.

The poop of DOOM · 2011-11-15 Reply Admin

Jim Fell:
trtrwtf:
However, I don't agree with Jim Fell's assertion that "high level languages produce inefficient code". That's off base two ways. First, modern language design is pretty good at making the obvious choice the right one. (except for occasional facepalms like overloading + for inefficient string concatenation in Java, that is) Second, and this is so obvious it hardly needs to be said, developer time is a part of "efficiency".

I wasn't saying that high level languages produce inefficient code. (Btw, I don't appreciate the misquote.) I was saying that high level languages more easily lend themselves to inefficient code for those programmers who don't understand what's actually happening when their code executes. That's not to say that that low-level languages can't be written inefficiently. In fact, they often are, but doing is usually less consequential (i.e. the inefficient construct is more efficient because a low-level language is used) or more disastrous (i.e. the code crashes or has other obvious run-time problems).

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 (unless you write it yourself, which you wouldn't, or wouldn't write well, if you'd write shitty code) than the same shitty code in a high-level language, which has garbage collection automatically included?

Back when I was a kid and was playing games in DOS, I always had to tweak memory to run this or that game. I absolutely hated Aldo Adventures cause it didn't clean up after itself, leaving a gaping memory hole behind. Fun game, but seriously huge memory leak! If you write the same simple game nowadays, and write it as shitty as they obviously did (otherwise, a little 8-year old kid wouldn't be cussing at something not cleaning up its memory usage), you won't have that memory loss after the game's been closed, thanks to those high-level languages.

So on one hand, yes. High-level languages allow people to write crappy code without any real consequences (besides maintenance and such). On the other hand, no. They're not worse than low-level languages because of that, since they actually keep it in mind and automatically provide tools that deal with the worst problems.

Severity One · 2011-11-15 Reply Admin

Matt Westwood:
Strike:
Severity One:
Anyway, Java does have operator overloading with the '+' operator, where 'a + b' is short for 'new StringBuffer(a).append(b).toString()'.
Oh they introduced it?
In 1.4 which I'm using there is no StringBuffer
Bloody is. Might not be a StringBuilder but there's defly a StringBuffer.

Indeed.

And I wrote my comment at three in the afternoon, whilst I get up at six in the morning, and despite that I'd been writing some damn good code before, my brain wasn't fried.

Then, in the evening, I totally sucked at playing Just Cause, but hey, can't have everything.

2011-11-15 Reply Admin

The poop of DOOM:
So on one hand, yes. High-level languages allow people to write crappy code without any real consequences (besides maintenance and such). On the other hand, no. They're not worse than low-level languages because of that, since they actually keep it in mind and automatically provide tools that deal with the worst problems.

I would consider allowing us to get away with writing crappy code by cleaning up our mess for us to be a major negative.

On the other hand, I don't consider not cleaning up the memory I've used because the language is designed to do that for me as "writing crappy code." It's using the language the way it was intended to be used.

The poop of DOOM · 2011-11-15 Reply Admin

Tom:
Iscu:
9 to 5 programmers, you gotta lov'em

Usually, these are 9 to 10 programmers, or 4 to 5 programmers, or even 9 to 9:30 and 4 to 4:30 programmers.

:-)

The rest of the time, they're sitting here, complaining about 9 to 5 programmers ;)

2011-11-15 Reply Admin

Oh they introduced it?
In 1.4 which I'm using there is no StringBuffer

Can't tell if this is a troll or not. Just in case, StringBuffer was introduced right at the start, version 1.0. The more efficient (for single-threaded usage) StringBuilder was introduced in 1.5.

2011-11-15 Reply Admin

Maurits:
itsmo:
Zylon:
Just for reference, how could be rewritten it in a single line:
Yoda is writing for DailyWTF now?

You mean:

Writing for DailyWTF Yoda now is.

Yoda uses "object, subject verb."

So it would be "Writing for DailyWTF now, Yoda is."

Corrected, I stand.

2011-11-15 Reply Admin

The poop of DOOM:
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?

Umm.... gosh if you put it that way, yes you should have some idea of what you are asking the machine to do, just like every other technical profession.

2011-11-15 Reply Admin

AC:
Can't tell if this is a troll or not. Just in case, StringBuffer was introduced right at the start, version 1.0. The more efficient (for single-threaded usage) StringBuilder was introduced in 1.5.

I am troll (this is a good thing), but in this case, I just forgot - Java and Java was soooooo long ago for me.

Anyway, strings in Java can be fucked up in various way

import java.lang.reflect.Field;
import java.lang.reflect.Modifier;

public class test {

    public static final String testString = "abcde";

    public static void main(String[] args) {
        try{
            System.out.println("Initial static final string:  "+testString);
            Field[] fields = testString.getClass().getDeclaredFields();
            Field value = null;
            for(int i=0; i<fields.length; i++){
                Field field = fields[i];
                if (field.getType().equals(char[].class)){
                    value = field;
                    break;
                }
            }
            if (value == null){
                System.err.println("value wasn't found!");
                return;
            }
            value.setAccessible(true);  // 1.
            char[] charValue = (char[])value.get(testString);
            for(int i=0; i<charValue.length/2; i++ ){
                char tmp=charValue[i];
                charValue[i] = charValue[charValue.length-1-i];
                charValue[charValue.length-1-i] = tmp;
            }
            value.set(testString, charValue);
            System.out.print("Reversed static final string: ");
            System.out.println(testString);
        }catch (Throwable th){
            System.err.println("Exception: "+th);
            th.printStackTrace();
        }
    }
}
</pre>

2011-11-15 Reply Admin

Nagesh:
Atmycompany,wearehavingsemepolicyregardingwhitespece.

You only use brainfuck then?

Severity One · 2011-11-15 Reply Admin

Strike:

Anyway, strings in Java can be fucked up in various way

[code omitted]

Yeah, but as soon as you start using reflection and setAccessible, all bets are off. It's like complaining that nuclear weapons are bad because they can be abused to kill people. Wait, hang on, that's perhaps not the best comparison...

2011-11-15 Reply Admin

Replacement:
    if(checkedStatus==null){
        return null; //Shouldn't never happen
    }
During code reviews, somebody I know likes to replace "should never happen" comments with:
System.exit(-1);
When the original coder complains, he simply points out that it should never happen, so the System.exit line shouldn't be a problem, right?

Defensive programming not a concept familiar to you? Or the difference between hard and soft failures? (Yeah, it's pretty obvious who that "somebody I know" douche is.)

2011-11-15 Reply Admin

airdrik:

//Shouldn't never happen

But my "hats off" to the "brilliant" architect who knew that it WOULD happen -- every time they add another enum value!!!

2011-11-15 Reply Admin

Just for reference, how could be rewritten it in a single line:
public Integer checkStatus(Status status){ return status.ordinal(); }

And then it could be inlined.

The poop of DOOM · 2011-11-15 Reply Admin

Jeff Grigg:
Just for reference, how could be rewritten it in a single line:
public Integer checkStatus(Status status){ return status.ordinal(); }

And then it could be inlined.

Somebody PLEEAASE think of the readability!

2011-11-15 Reply Admin

jverd:
+9:
TRWTF is Java, as always. Mwahaha

How terribly original. That never gets old and is not the least bit obvious or pathetic or unfunny. I hope every single wtf that even mentions Java, or where any of the people involved have ever heard of Java, or have drunk a cup of coffee, makes the hilarious observation that "TRWTF is Java", as this shows a level of insight and sophistication that can do naught but elevate the value of this site, propelling its humor and educational value to the stratosphere.

Thank you so much, my friend. We all owe you an enormous debt of gratitude. And, though it be rude of me in the extreme to dare ask more of you, might I please entreat you to come to my house every morning and wake me up be screaming in my ear that "TRWTF is Java"? Being reminded of that perfectly correct, perfectly valuable, always relevant, never trite, and forever inspirational bit of wisdom is the best way I can imagine to start my day, short of feeding my nuts into a meat grinder while squirting boiling dog vomit up my nose.

Thanks for the reply, it was awesome :) Though a bit bloated...

2011-11-15 Reply Admin

jverd:
+9:
TRWTF is Java, as always. Mwahaha

How terribly original. That never gets old and is not the least bit obvious or pathetic or unfunny. I hope every single wtf that even mentions Java, or where any of the people involved have ever heard of Java, or have drunk a cup of coffee, makes the hilarious observation that "TRWTF is Java", as this shows a level of insight and sophistication that can do naught but elevate the value of this site, propelling its humor and educational value to the stratosphere.

Thank you so much, my friend. We all owe you an enormous debt of gratitude. And, though it be rude of me in the extreme to dare ask more of you, might I please entreat you to come to my house every morning and wake me up be screaming in my ear that "TRWTF is Java"? Being reminded of that perfectly correct, perfectly valuable, always relevant, never trite, and forever inspirational bit of wisdom is the best way I can imagine to start my day, short of feeding my nuts into a meat grinder while squirting boiling dog vomit up my nose.

TRWTF is unfunny wall of text

2011-11-15 Reply Admin

I really like Java Enums because they can be used to extend other classes or implement interfaces, and create a set of related singleton classes. Also the ability to create an abstract method in an enum makes things like a set of comparators for an object, functions, and filters easy to manage. It's nice to be able to write something like transactions.Sort(Transaction.Comparators.PRICE), or filter.execute(parameter1, parameter2). The nice thing is that the enum can be used by the UI to make a drop-down of available Comparators.

Skyrider · 2011-11-15 Reply Admin

Zylon:
Yoda is writing for DailyWTF now?

"The dark side of the source clouds everything. Impossible to see the feature is."

The poop of DOOM · 2011-11-15 Reply Admin

Skyrider:
Zylon:
Yoda is writing for DailyWTF now?

"The dark side of the source clouds everything. Impossible to see the feature is."

So you're saying that The Cloud (handwave gesture) is blocking any and all features?

2011-11-15 Reply Admin

Nagesh:
Totally agree. In most cases, the true integer value of an enum should not be of any relevance (the major exception being storing to a database). If it is, make sure you have a good reason. Since this function gets the integer value of an enum, its existence points to a bigger possible problem with the program architecture. As a long time C++ programmer, I understand how easy it is to think of enums as integers and it is one of the things I always hated about the language.

The scary thing is that the people who made Java seem to agree, and only made the ordinal visible as a sort of afterthought.

2011-11-15 Reply Admin

[image]

Nagesh · 2011-11-15 Reply Admin

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".

Bad News Enum

Leave a comment on “Bad News Enum”