Enum Idiom Question
in [Java Programming]
|
From: Arne Vajhøj on 29 May 2010 19:37 On 29-05-2010 17:20, Rhino wrote: > "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message > news:4c006f2d$0$278$14726298(a)news.sunsite.dk... >> On 28-05-2010 20:43, Rhino wrote: >>> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message >>> news:4c005ae9$0$281$14726298(a)news.sunsite.dk... >>>> On 28-05-2010 19:02, Rhino wrote: >>>>> It's the if statement that concerns me here. This code works fine (I >>>>> can >>>>> test for CompletionStatus.NO_ERROR by simply changlng the right side of >>>>> the >>>>> if) but it doesn't look right. It reminds me of mistakes I made when I >>>>> was >>>>> new to Java comparing Strings to each other via the == operator to see >>>>> if >>>>> they had the same VALUE but discovering that == doesn't determine >>>>> equality >>>>> of value. >>>> >>>>> Is there a better way to do this if statement? If so, what is it? >>>> >>>> I would compare with CompletionStatus.NO_ERROR, because it is >>>> a lot more likely that you will have more than one error status >>>> than more than one no error status. >>>> >>> Okay, that's fair. But am I writing the comparison correctly? That == >>> operator looks wrong somehow, even if it works. I'm concerned that this >>> might be like comparing two Strings with the == operator; sometimes it >>> will >>> show equality and make you think it is confirming equality of value >>> between >>> the two strings but it is not; you have to use equals() to compare String >>> values. But I'm not sure what the equivalent is for an enum. >> >> == on enums are fine. >> >> Object identity is exactly what is needed. >> > > Thank you, Arne! I wasn't able to find that idiom anywhere I looked so it's > good to hear I got it right although I expect that was more luck than brains > ;-) > > By the way, WHERE is that documented? The Enum class in the Java API > includes an equal() method and the tutorials I read about enum and the Sun > site don't mention that idiom at all... That is actually a good question. I am sure that you can find it in the JLS (Java Language Specification). Same in the enum JSR for Java 1.5. You can also see it if you examine the generated byte code or look at the source of Enum.java. Neither should be necessary for such a basic question. Heavy googling managed to find: http://java.sun.com/docs/books/tutorial/reflect/special/enumSetGet.html <quote> Since the enum constants are singletons, the == and != operators may be used to compare enum constants of the same type. </quote> But that was not obvious. I am afraid that the answer is that most Java programmers either use one of the first mentioned methods or know somebody that does. Arne
From: Rhino on 30 May 2010 13:09 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4c01a532$0$282$14726298(a)news.sunsite.dk... > On 29-05-2010 17:20, Rhino wrote: >> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message >> news:4c006f2d$0$278$14726298(a)news.sunsite.dk... >>> On 28-05-2010 20:43, Rhino wrote: >>>> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message >>>> news:4c005ae9$0$281$14726298(a)news.sunsite.dk... >>>>> On 28-05-2010 19:02, Rhino wrote: >>>>>> It's the if statement that concerns me here. This code works fine (I >>>>>> can >>>>>> test for CompletionStatus.NO_ERROR by simply changlng the right side >>>>>> of >>>>>> the >>>>>> if) but it doesn't look right. It reminds me of mistakes I made when >>>>>> I >>>>>> was >>>>>> new to Java comparing Strings to each other via the == operator to >>>>>> see >>>>>> if >>>>>> they had the same VALUE but discovering that == doesn't determine >>>>>> equality >>>>>> of value. >>>>> >>>>>> Is there a better way to do this if statement? If so, what is it? >>>>> >>>>> I would compare with CompletionStatus.NO_ERROR, because it is >>>>> a lot more likely that you will have more than one error status >>>>> than more than one no error status. >>>>> >>>> Okay, that's fair. But am I writing the comparison correctly? That == >>>> operator looks wrong somehow, even if it works. I'm concerned that this >>>> might be like comparing two Strings with the == operator; sometimes it >>>> will >>>> show equality and make you think it is confirming equality of value >>>> between >>>> the two strings but it is not; you have to use equals() to compare >>>> String >>>> values. But I'm not sure what the equivalent is for an enum. >>> >>> == on enums are fine. >>> >>> Object identity is exactly what is needed. >>> >> >> Thank you, Arne! I wasn't able to find that idiom anywhere I looked so >> it's >> good to hear I got it right although I expect that was more luck than >> brains >> ;-) >> >> By the way, WHERE is that documented? The Enum class in the Java API >> includes an equal() method and the tutorials I read about enum and the >> Sun >> site don't mention that idiom at all... > > That is actually a good question. > > I am sure that you can find it in the JLS (Java Language > Specification). > > Same in the enum JSR for Java 1.5. > > You can also see it if you examine the generated byte code > or look at the source of Enum.java. > > Neither should be necessary for such a basic question. > > Heavy googling managed to find: > > http://java.sun.com/docs/books/tutorial/reflect/special/enumSetGet.html > > <quote> > Since the enum constants are singletons, the == and != operators may be > used to compare enum constants of the same type. > </quote> > > But that was not obvious. > > I am afraid that the answer is that most Java programmers either > use one of the first mentioned methods or know somebody that does. > Sorry, I didn't mean to make work for you. I assumed that was one of those questions that you experts can answer off the top of your head :-) Thanks for your help! -- Rhino
From: Rhino on 30 May 2010 13:09 "Lew" <noone(a)lewscanon.com> wrote in message news:hts11j$4re$1(a)news.albasani.net... > Arne Vajh�j wrote: >>> == on enums are fine. >>> >>> Object identity is exactly what is needed. > > Rhino wrote: >> Thank you, Arne! I wasn't able to find that idiom anywhere I looked so >> it's >> good to hear I got it right although I expect that was more luck than >> brains >> ;-) >> >> By the way, WHERE is that documented? The Enum class in the Java API >> includes an equal() method > > Yes, it does, and if you read the docs there you find: > public final boolean equals(Object other) > telling you that it cannot be overridden and that it "returns true if the > specified object is equal to this enum constant." > > From the definition of what an enum is in the language, you know that > there can only be one instance of an enum constant. Ergo, the only way > that an enum's 'equals()' method can return 'true' is if object identity > holds, and therefore the enum's 'equals()' method is functionally > equivalent to '=='. > > Even without that, you know that the 'equals()' method is safe to use. > Thank you! -- Rhino
From: Rhino on 30 May 2010 13:10 "Lew" <noone(a)lewscanon.com> wrote in message news:hts0js$46k$1(a)news.albasani.net... > Rhino wrote: >>>>> But am I writing the comparison correctly? That == >>>>> operator looks wrong somehow, even if it works. I'm concerned that >>>>> this >>>>> might be like comparing two Strings with the == operator; sometimes it >>>>> will >>>>> show equality and make you think it is confirming equality of value >>>>> between >>>>> the two strings but it is not; you have to use equals() to compare >>>>> String >>>>> values. But I'm not sure what the equivalent is for an enum. > > Lew wrote: >>> This is fully covered in the docs for enums, ... > > Rhino wrote: > >> In fact, I _did_ read some Java articles on enums and they did NOT >> mention >> that the == operator was the correct one to use. > > By "the docs" I'm referring to the JLS and the Javadocs, which are the > primary sources. They don't quite cover everything, but they are > canonical as far as they go. > > To whit, the chapter of the language spec that actually defines enums: > <http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.9> > says, in paragraph 2 of the first "Discussion" sidebar, > > "Because there is only one instance of each enum constant, it is > permissible to use the == operator in place of the equals method when > comparing two object references if it is known that at least one of them > refers to an enum constant. (The equals method in Enum is a final method > that merely invokes super.equals on its argument and returns the result, > thus performing an identity comparison.)" > Thank you. -- Rhino
From: Rhino on 30 May 2010 13:13
"Lew" <noone(a)lewscanon.com> wrote in message news:hts0a6$3qg$1(a)news.albasani.net... > Rhino wrote: >> There seems to be a considerably body of opinion that Exceptions are >> overkill for relatively minor things like bad input parameters and that >> they >> should be reserved for more severe problems. > > The dichotomy is not between "minor" and "severe" but between "in band" > and "out of band". > > You misconstrue if you think that there is a "minor" or "severe" > "problem". > > The design decision, and the point of divergence of opinion, is what > constitutes "in" or "out of" band. > > If you design that bad inputs are "in band", bad input won't throw an > exception. > If you design that bad inputs are "out of band", bad input will throw an > exception. Then you decide between checked and runtime exceptions. > > The degree to which the exception propagates, and the decision about in or > out of band, depend in part on how low-level the routine in question is. > > There are different strategies for logging, too. > > As long as you ask the good questions, e.g., "Is bad input in band or out > of band?", you'll tend make good decisions either way. Bad questions, "Is > bad input minor or severe?", tend to lead to bad decisions either way. > Well, perhaps the "in band/out of band" dichotomy is a better way to phrase my question. But I had not heard this specific terminology before so it didn't come to mind when I was writing the post. I'll try to keep in mind that you prefer this terminology over other words and phrases. -- Rhino |