enum and switch

[Tor Iver Wilhelmsen]

Fully qualifying the constant should have produced a warning about an
unnecessary cast. IMHO of course

Casting does not enter into the picture: Since "case foo:" can only take a
constant primitive expression as foo, the compiler obtains the literal
value of the enum and puts it into the method code.

 

[Tor Iver Wilhelmsen]

That still does not explain why qualification is prohibited. It would
appear to be harmless, and in some situations make code more orthogonal,
provided the types match.

The compiler's rule enforces that the types match.

Using enums in switch statements is exactly equivalent to using their
literals in a "normal" switch statement. And the range of an enum is its
values: It's pointless to even add a hint of ambiguity by allowing other
constant expressions than the enum's synthesized instances.

 

[Patricia Shanahan]

The compiler's rule enforces that the types match.

Using enums in switch statements is exactly equivalent to using their
literals in a "normal" switch statement. And the range of an enum is its
values: It's pointless to even add a hint of ambiguity by allowing other
constant expressions than the enum's synthesized instances.

Agreed. The only question I'm asking is why the language prohibits
correct qualification of the instance name. Why can't one use
"Things.ONE", where "Things" is the type of the enum expression in the
switch, and "ONE" is one of its value identifiers?

This is not about what expressions can be used in the case, just about
what syntax is permitted in naming them.

I can imagine situations in which human readability would be improved by
allowing qualification.

For example, suppose two enums, designed separately, use the same
instance identifier with different meanings. The compiler will always
remember the type of the switch expression, and pick the right "ONE"
based on that. A human might see "ONE" and think "Widget.ONE" even if it
should be "Things.ONE", especially if the rest of the uses of "ONE" in
the class are "Widget.ONE".

Patricia

 

[Wojtek]

Wojtek wrote :

private static int LOGIC_AND_ID = 0;
private static int LOGIC_OR_ID = 1;

These should be:
private static final int LOGIC_AND_ID = 0;
private static final int LOGIC_OR_ID = 1;

Late in the day....

 

[Wojtek]

Patricia Shanahan wrote :

Agreed. The only question I'm asking is why the language prohibits
correct qualification of the instance name. Why can't one use
"Things.ONE", where "Things" is the type of the enum expression in the
switch, and "ONE" is one of its value identifiers?

This is not about what expressions can be used in the case, just about
what syntax is permitted in naming them.

I can imagine situations in which human readability would be improved by
allowing qualification.

And further to this, I can use:
java.util.HashMap<String,String> x;
or
HashMap<String,String> x;

Both are acceptable (barring imports). The switch statement is the
first place I have found where you CANNOT use a qualified name.

 

[Chris Uppal]

This is not about what expressions can be used in the case, just about
what syntax is permitted in naming them.

I can imagine situations in which human readability would be improved by
allowing qualification.

It's even worse (IMO) if there's another definition of of the enumeration
element's name which would normally be expected to hide the other identifier.
I find the attached code particularly unpleasant. See how in one case the
compiler /requires/ qualification, in another it /forbids/ it.

-- chris


=======================
enum Number
{
ONE,
TWO
}

public class Test
{
private static final int
ONE = 1,
TWO = 2;

public static void
main(String[] args)
{
Number n = Number.ONE;
/* Number nn = ONE; -- error: incompatible types */

int m = ONE;
int mm = Test.ONE;

switch (n)
{
case ONE:
System.out.println("n is Number.ONE");
break;
case TWO:
System.out.println("n is Number.TWO");
break;
}

/* not legal at all....
switch (n)
{
case Number.ONE:
System.out.println("n is Number.ONE");
break;
case Number.TWO:
System.out.println("n is Number.TWO");
break;
}
*/

switch (m)
{
case ONE:
System.out.println("m is Number.ONE");
break;
case TWO:
System.out.println("m is Number.TWO");
break;
}

switch (m)
{
case Test.ONE:
System.out.println("m is Number.ONE");
break;
case Test.TWO:
System.out.println("m is Number.TWO");
break;
}

}
}
=======================

 

[Andreas Leitgeb]

It's even worse (IMO) if there's another definition of of the enumeration
element's name which would normally be expected to hide the other identifier.
I find the attached code particularly unpleasant.

It's not all that bad: Wherever you could actually use an
*any*-qualified item, you can add a qualification.

Wherever only one qualification is possible, it's implicit
and you don't specify it.

enum Number { ONE, TWO }

add this:
class Foo { static final Number ONE=Number.TWO; static final int TWO=1; }

public class Test {
private static final int ONE = 1, TWO = 2;
[... inside main() ...]
Number n = Number.ONE;
/* Number nn = ONE; -- error: incompatible types */

of course!
since ONE is wrong type, but you could just as legally use FoNE
here and you couldn't use that in a switch.

 

[John W. Kennedy]

Agreed. The only question I'm asking is why the language prohibits
correct qualification of the instance name. Why can't one use
"Things.ONE", where "Things" is the type of the enum expression in the
switch, and "ONE" is one of its value identifiers?

I smell a reaction to the quarrel over whether "myWidget.widgetCount()"
should have been allowed as an alias of "Widget.widgetCount()".

--
John W. Kennedy
"I want everybody to be smart. As smart as they can be. A world of
ignorant people is too dangerous to live in."
-- Garson Kanin. "Born Yesterday"
* TagZilla 0.066 * http://tagzilla.mozdev.org