3.2.3 Identifiers

   An identifier is an arbitrarily long sequence of ASCII alphabetic, digit, and underscore (“_?) characters. The first character must be an ASCII alphabetic character. All characters are significant.

   When comparing two identifiers to see if they collide:

• Upper- and lower-case letters are treated as the same letter. Table 3-2 on page 3-3 defines the equivalence mapping of upper- and lower-case letters.

• All characters are significant.

   Identifiers that differ only in case collide, and will yield a compilation error under certain circumstances. An identifier for a given definition must be spelled identically (e.g., with respect to case) throughout a specification.

   There is only one namespace for OMG IDL identifiers in each scope. Using the same identifier for a constant and an interface, for example, produces a compilation error.

   For example:

   module M {typedef long Foo;const long thing = 1;

   interface thing { // error: reuse of identifier void doit ( in Foo foo // error: Foo and foo collide and refer to different things );

   readonly attribute long Attribute; // error: Attribute collides with keyword attribute }; };

   3.2.3.1 Escaped Identifiers

   As IDL evolves, new keywords that are added to the IDL language may inadvertently collide with identifiers used in existing IDL and programs that use that IDL. Fixing these collisions will require not only the IDL to be modified, but programming language code that depends upon that IDL will have to change as well. The language mapping rules for the renamed IDL identifiers will cause the mapped identifier names (e.g., method names) to be changed.

   To minimize the amount of work, users may lexically “escape? identifiers by prepending an underscore (_) to an identifier. This is a purely lexical convention that ONLY turns off keyword checking. The resulting identifier follows all the other rules for identifier processing. For example, the identifier _AnIdentifier is treated as if it were AnIdentifier.

   The following is a non-exclusive list of implications of these rules:

• The underscore does not appear in the Interface Repository.

• The underscore is not used in the DII and DSI.

• The underscore is not transmitted over “the wire.?

• Case sensitivity rules are applied to the identifier after stripping off the leading underscore.

   For example:

   module M { interface thing { attribute boolean abstract; // error: abstract collides with // keyword abstract attribute boolean _abstract; // ok: abstract is an identifier }; };

   To avoid unnecessary confusion for readers of IDL, it is recommended that interfaces only use the escaped form of identifiers when the unescaped form clashes with a newly introduced IDL keyword. It is also recommended that interface designers avoid defining new identifiers that are known to require escaping. Escaped literals are only recommended for IDL that expresses legacy interface, or for IDL that is mechanically generated.