Issue 545:  Enums and enumerators (orb_revision)
Source:  (, )
Nature:  Uncategorized
Severity: 
Summary: Summary: Sec 3.13 says enumerators don"t create a nested scope.Implication: 2 differnt enum types within same module can"t have same enumerator names. Flag following example as an error

Resolution:  issue closed, no change
Revised Text: 
Actions taken:
April 10, 1997: received issue
February 23, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <daemon>
Date: Thu, 10 Apr 1997 18:03:04 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard New Jersey Labs
Cc: David Bell <dibl@hpprsd1.sc.hp.com>
Subject: Enums and enumerators
Errors-To: owner-orb_revision
Sender: owner-orb_revision
X-OMG: orb_revision
To: orb_revision

Section 3.13 says that enumerators do not create a nested scope. The
implication of this is that two different enum types within the same
module cannot have the same enumerator names. With the most plausible
interpretation of what is in the spec the following example should be
flagged as an error:

	module Foo {

		enum Enum1 { Red, Blue, Green };
		enum Enum2 {White, Pink, Red};

	};

since the value of the enumerator Red is multiply defined. The
interpretation follows from the statement that enums do not create a
nested scope, hence all names of enumerators for an enum are in the
scope in which the enum is defined. 

Was this intentional or was this an oversight?

This peculiar feature of IDL forces people to define unfriendly
enumerator names as in the following example (to be on the safe side):

	module Foo {
		
		enum Enum1 { Enum1Red, Enum1Blue, Enum1Green };
		enum Enum2 { Enum2White, Enum2Pink, Enum2Red };

	};

and thus have human beings play the role of name mungers in C++
compilers, whereas this could have easily been avoided by having enums
create a nested scope and the enumerator names defined within that
scope.

We had faced this problem while working on the Security specification,
and finally of course went ahead and acted like C++ compiler name
mungers and explicitly scoped all enumerators with the name of their
Enum type.

So was their a specific reason for enums not to create a nested scope
for the name of its enumerators? If not should'nt this be fixed at some
point?

Jishnu Mukerji



Return-Path: <daemon>
Date: Thu, 10 Apr 1997 16:07:00 -0700
From: Jonathan Biggar <jon@sems.com>
Organization: Seagate Enterprise Management Software
Cc: orb_revision@omg.org, David Bell <dibl@hpprsd1.sc.hp.com>
Subject: Re: Enums and enumerators
References: <334D6398.5A09@fpk.hp.com>
Errors-To: owner-orb_revision
Sender: owner-orb_revision
X-OMG: orb_revision
To: orb_revision

Enumerators are done this way because it is the way that C and C++ have
always done it.

You would have to refer to your enumerators as Foo::Enum1::Red
and Foo::Enum2::Red, which would break all existing code using
enumerators, as well as cause havoc with the C & C++ bindings.

Jon

Jishnu Mukerji wrote:
> 
> Section 3.13 says that enumerators do not create a nested scope. The
> implication of this is that two different enum types within the same
> module cannot have the same enumerator names. With the most plausible
> interpretation of what is in the spec the following example should be
> flagged as an error:
> 
>         module Foo {
> 
>                 enum Enum1 { Red, Blue, Green };
>                 enum Enum2 {White, Pink, Red};
> 
>         };
> 
> since the value of the enumerator Red is multiply defined. The
> interpretation follows from the statement that enums do not create a
> nested scope, hence all names of enumerators for an enum are in the
> scope in which the enum is defined.
> 
> Was this intentional or was this an oversight?
> 
> This peculiar feature of IDL forces people to define unfriendly
> enumerator names as in the following example (to be on the safe side):
> 
>         module Foo {
> 
>                 enum Enum1 { Enum1Red, Enum1Blue, Enum1Green };
>                 enum Enum2 { Enum2White, Enum2Pink, Enum2Red };
> 
>         };
> 
> and thus have human beings play the role of name mungers in C++
> compilers, whereas this could have easily been avoided by having enums
> create a nested scope and the enumerator names defined within that
> scope.
> 
> We had faced this problem while working on the Security specification,
> and finally of course went ahead and acted like C++ compiler name
> mungers and explicitly scoped all enumerators with the name of their
> Enum type.
> 
> So was their a specific reason for enums not to create a nested scope
> for the name of its enumerators? If not should'nt this be fixed at some
> point?