Case expression must be constant expression

[Roedy Green]

This has been a bugbear of mine since university days. I have often
accused profs of making the simple sound complicated in order to
impress rather than inform. Did you ever read the Algol 68 report? It
is a classic case.

We studied proof after proof in mathematics, but we never saw how one
was actually constructed. It was like studying building construction
without ever seeing anything but a completed building. Mathematicians
were embarrassed about the way intuition and refinement went into a
polished elegant, minimalist proof. They wanted to hide every trace
the scaffolding had ever existed.

Similarly when we were studying group and ring theory, the profs would
smack us down if we ever tried to think about concrete examples
worked. This would contaminate your thinking they asserted. You would
make unwarranted assumptions that applied only to special cases. They
wanted you to argue and think purely from the abstract. I could see
insisting your final proof was purely abstract, but I could not see
why it was so wicked to use concrete examples to give your mind
something concrete to think about.

As a kid I used to sell "cheat sheets" to fellow students for 5 cents
each to give them rules of thumb, and intuitive hooks to help them
solve math, physics, chemistry and genetics problems. Human problem
solving is a sloppier trial-and-error business than we pretend.

One beauty of the Internet is anyone is free to compose instructional
materials with any degree of informality they please.

My contention is humans are superb at generalising from a well-chosen
set of examples. This is much easier than absorbing abstract rules.
This is what you would expect since experience teaches by example.
This is how all animals learn. Very rarely do you get presented with
an abstract theory. Consider how much easier arithmetic is for a
calculator than for a human. We humans are relatively inept even at
applying the relatively simple rules of arithmetic.

Yet a human can solve a difficult problem like who would make a
suitable roommate, one that can be thought of as reasoning from many
examples.

 

[Roedy Green]

There are seven?

see http://mindprod.com/jgloss/constant.html

for the seven types. There categories are mine, nothing official in
Java.

 

[Ed Kirwan]

Daniel Pitts wrote:

In Object Oriented design, its considered a likely problem if you have a
switch statement (or a switch like construct). While there are *some*
times when a switch is appropriate, I've found that I haven't used a
switch statement once I understood the State, Strategy, and Flyweight
patterns.

Hej, Daniel,

Would you say that a switch statement is inappropriate in a parameterised
factory method, such as the one below?

http://www.edmundkirwan.com/servlet/fractal/cs1/code/package101.html#getEvaluation

And if inappropriate, how should parameterised factory methods look? Or
would you say that parameterised factory methods are inherently un-OO?

I'm curious because I use them quite a lot and am wondering whether I should
drop them in favour of something else.

 

[Philipp]

What're you working on?
Maybe someone has a better suggestion than an if ladder.

Yes, actually I was trying to make a replacement for an Enum in JRE 1.3
when I stumbled accross this "Constant in case expression" problem.

What I made to mimic an enum is a class with static final members of
itself inside (see example code below). But in this case I can't use the
ordinal in a switch statement...

Phil


--SSCE-- (notice the missing C

import java.util.HashMap;

public class Month{
private final int ordinal;
private static final HashMap correspondanceMap = new HashMap();

private Month(int ordinal) {
this.ordinal = ordinal;
correspondanceMap.put(new Integer(ordinal), this);
}

public static final Month JANUARY = new Month(1);
public static final Month FEBRUARY = new Month(2);
public static final Month MARCH = new Month(3);
public static final Month APRIL = new Month(4);

public int getOrdinal(){
return ordinal;
}

public static Month byOrdinal(int ordinal){
return (Month)correspondanceMap.get(new Integer(ordinal));
}


public int hashCode() { return ordinal; }

public boolean equals(Object h_type){
if (!(h_type instanceof Month)) return false;
if ( ((Month)h_type).getOrdinal() == getOrdinal()) return true;
else return false;
}


public static void main(String[] args) {
System.out.println("April's ordinal is: " + Month.APRIL.getOrdinal());


Month m = Month.byOrdinal(2);
if(m.equals(Month.FEBRUARY)){
System.out.println("Both are equal.");
}

// switch doesn't work
int choice = 3;
switch(choice){
case Month.JANUARY.getOrdinal():
System.out.println("Do something for January");
case Month.FEBRUARY.getOrdinal():
System.out.println("Do something for February");
case Month.MARCH.getOrdinal():
System.out.println("Do something for March");
case Month.APRIL.getOrdinal():
System.out.println("Do something for April");
default:
System.out.println("None of those months");
}
}
}

 

[Lew]

Yes, actually I was trying to make a replacement for an Enum in JRE 1.3
when I stumbled accross this "Constant in case expression" problem.

Check out the "type-safe enum", as explained by Joshua Bloch in /Effective
Java/, for example.

 

[Daniel Pitts]

Daniel Pitts wrote:



Hej, Daniel,

Would you say that a switch statement is inappropriate in a parameterised
factory method, such as the one below?

http://www.edmundkirwan.com/servlet/fractal/cs1/code/package101.html#getEvaluation

And if inappropriate, how should parameterised factory methods look? Or
would you say that parameterised factory methods are inherently un-OO?

I'm curious because I use them quite a lot and am wondering whether I should
drop them in favour of something else.

In your example, where does rank come from?
Is it assigned specific values based on another if/else block?

This seems to me to fit my example of using an enum as a flyweight:
<http://virtualinfinity.net/wordpress/program-design/2007/10/22/using-enums-as-a-flyweight-pattern/>

Basically, you have a Rank abstract class/interface which has the
implementations HighestCard, OnePair, TwoPairs, etc....

The interface would have a HandEvaluation getEvaluation(Hand hand);
Your factory method could remain. It would simply delegate to
rank.getEvaluation(hand);

 

[Ramon F Herrera]

Just a gentle suggestion - please take the care to use full words and spacing.
Txtspeek is awful stuff and looks unbelievably illiterate. It also makes
the message harder to read.

I agree with you, Lew. It seems that we have a whole generation of
people who has learned how to type on cell phones and IMs!

-Ramon