Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > enum and switch

Reply
Thread Tools

enum and switch

 
 
Tor Iver Wilhelmsen
Guest
Posts: n/a
 
      03-08-2007
På Wed, 07 Mar 2007 20:16:36 +0100, skrev Wojtek <(E-Mail Removed)>:

> 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.
 
Reply With Quote
 
 
 
 
Tor Iver Wilhelmsen
Guest
Posts: n/a
 
      03-08-2007
På Thu, 08 Mar 2007 03:58:32 +0100, skrev Patricia Shanahan <(E-Mail Removed)>:

> 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.
 
Reply With Quote
 
 
 
 
Patricia Shanahan
Guest
Posts: n/a
 
      03-08-2007
Tor Iver Wilhelmsen wrote:
> På Thu, 08 Mar 2007 03:58:32 +0100, skrev Patricia Shanahan <(E-Mail Removed)>:
>
>> 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.


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
 
Reply With Quote
 
Wojtek
Guest
Posts: n/a
 
      03-09-2007
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


 
Reply With Quote
 
Wojtek
Guest
Posts: n/a
 
      03-09-2007
Patricia Shanahan wrote :
> Tor Iver Wilhelmsen wrote:
>> P Thu, 08 Mar 2007 03:58:32 +0100, skrev Patricia Shanahan <(E-Mail Removed)>:
>>
>>> 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.

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

--
Wojtek


 
Reply With Quote
 
Chris Uppal
Guest
Posts: n/a
 
      03-09-2007
Patricia Shanahan wrote:

> 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;
}

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


 
Reply With Quote
 
Andreas Leitgeb
Guest
Posts: n/a
 
      03-09-2007
Chris Uppal <(E-Mail Removed)-THIS.org> wrote:
> 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 Foo.ONE
here and you couldn't use that in a switch.


 
Reply With Quote
 
John W. Kennedy
Guest
Posts: n/a
 
      03-09-2007
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?


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Difference between enum class and enum struct Brian C++ 4 02-27-2010 04:03 PM
enum: display elements of an enum specified at runtime Jerminia Java 3 10-07-2005 10:08 PM
enum within an enum - Java 6 06-13-2005 12:51 AM
Including an enum within another enum, possible? mrhicks C Programming 2 06-10-2004 03:00 AM
How to enum an enum? Ernst Murnleitner C++ 5 11-13-2003 11:06 AM



Advertisments