Issue 1900: New name clash issue from CORBA 2.3 spec (mof-rtf) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: The ORB revision task force is proposing a change to the CORBA IDL spec that forbids the redefinition of an identifier in the immediate scope of an interface or module. This impacts on MOF IDL generation. Resolution: resolved and closed Revised Text: Actions taken: August 31, 1998: received issue May 8, 2000: closed issue Discussion: The latest draft revision of the CORBA chapter 3 spec says: "The name of an interface or a module may not be redefined within the immediate scope of the interface of the module. For example: module M { typedef short M; // Error: M is the name of the module // in the scope of which the typedef is. interface I { void i (in short j); // Error: i clashes with the interface name I }; };" This change was forced into the IDL spec by name mangling problems in the C++ lan-guage mapping. I think that we have two alternative ways to track this change in the MOF: 1. Change the M2 level scoping rules so that this above restriction applies to all MOF meta-models. 2. Add an extra bullet point to 7.4 to make the above restriction a preconditions for successful IDL generation. Option 2) is prefereable because it leaves open the possibility that the IDL and / or C++ mapping specs may be revised to fix the problem properly. [Don't hold your breath though ... ]. Also, there are apparently a number of other cases where name mangling in CORBA language mappings gives rise to uncompilable code from valid IDL. If we word the text cor-rectly, we can cover all of these cases as well. Proposed resolution: Update the "preconditions for IDL generation" section to cover these cases Washington : Resolved, to be implemented using option 2. Implementation: Added text to advise against using names that would violate this new IDL constraint in Section 5.5, “Preconditions for IDL Generation,” on page 5-33. Done [KR]. End of Annotations:===== Return-Path: To: mof-rtf@omg.org, issues@omg.org Subject: New name clash issue from CORBA 2.3 spec Date: Mon, 31 Aug 1998 18:22:16 +1000 From: Stephen Crawley Source: DSTC (Dr. Stephen Crawley, crawley@dstc.edu.au) Nature: Revision Severity: Minor Summary: The ORB revision task force is proposing a change to the CORBA IDL spec that forbids the redefinition of an identifier in the immediate scope of an interface or module. This impacts on MOF IDL generation. Extra text: The latest draft revision of the CORBA chapter 3 spec says: "The name of an interface or a module may not be redefined within the immediate scope of the interface of the module. For example: module M { typedef short M; // Error: M is the name of the module // in the scope of which the typedef is. interface I { void i (in short j); // Error: i clashes with the interface name I }; };" This change was forced into the IDL spec by name mangling problems in the C++ language mapping. I think that we have two alternatives to track this change in the MOF: 1) Change the OCL rules for scoping at the M2 level. 2) Add an extra bullet point to 7.4 which lists the preconditions for sucessfull IDL generation. I prefer option 2), because it leaves open the possibility that the IDL and / or C++ mapping specs may be revised to fix the problem properly. [Don't hold your breath though ... ]. Also, there are apparently a number of other cases where name mangling in CORBA language mappings gives rise to uncompilable code from valid IDL. If we word the text correctly, we can cover all of these cases as well. -- Steve Return-Path: Sender: jis@fpk.hp.com Date: Mon, 31 Aug 1998 11:23:13 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Juergen Boldt Cc: issues@omg.org, mof-rtf@omg.org Subject: Re: issue 1900 -- MOF RTF Issue References: <3.0.32.19980831101240.00a17c3c@emerald.omg.org> Juergen Boldt wrote: > > This is issue # 1900 > > New name clash issue from CORBA 2.3 spec > > The ORB revision task force is proposing a change to the > CORBA IDL spec that forbids the redefinition of an identifier in > the immediate scope of an interface or module. This impacts on > MOF IDL generation. To be fair it should also be stated that even if the Core RTF did not propose this change, any IDL that does not follow this restriction leads to the generationof uncompilable C++ (and perhaps Java) code. So even without this proposed change from the Core RTF, MOF and any other IDL generation schemes should avoid generating IDL that does not follow this restriction, if they care to have the IDL produced by their IDL generator, used to generate compilable C++ code:-). Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: To: Jishnu Mukerji cc: Juergen Boldt , issues@omg.org, mof-rtf@omg.org, crawley@dstc.edu.au Subject: Re: issue 1900 -- MOF RTF Issue Date: Tue, 01 Sep 1998 14:51:47 +1000 From: Stephen Crawley Jishnu wrote: > To be fair it should also be stated that even if the Core RTF did > not > propose this change, any IDL that does not follow this restriction > leads > to the generationof uncompilable C++ (and perhaps Java) code. So > even > without this proposed change from the Core RTF, MOF and any other > IDL > generation schemes should avoid generating IDL that does not follow > this > restriction, if they care to have the IDL produced by their IDL > generator, used to generate compilable C++ code:-). I was not intending to imply that the Core RTF change is inappropriate. Given that the C++ mapping's idiosyncrasies are so firmly entrenched, this is the only viable short term solution. I also recognise that a long term solution that fixes the C++ mapping is unlikely to occur in the lifetime of CORBA as we know it. It turns out that we had already encountered this problem in the C++ mapping. We wanted the MOF's IDL mapping to map every MOF Package onto an IDL module that contained an IDL interface with the same name; e.g. package Foo { type Bar { }; }; would map to module Foo interface Foo { ... }; // the Foo package interface interface BarClass { ... }; // the Bar class instance interface interface Bar : BarClass { ... }; // the Bar instance interface }; But we found that this IDL did not give compilable with the Orbix IDL compiler. Unfortunately, we diagnosed this as a bug in the Orbix IDL compiler ... rather than a problem in the C++ mapping. Anyhow, to be on the safe side we changed the MOF IDL mapping so that the Foo interface became the FooPackage interface. -- Steve