Issue 3054: messaging issues: name clashes from implied IDL (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: The name conflict resolution algorithm for implied-IDL operations and attributes (based on inserting "_ami" strings) does not cover all possible name conflicts. Example: // IDL interface A { void op (); }; interface B { void sendp_op() }; The implied-IDL operation A::sendp_op conflicts with B::sendp_op. -> Thus, according to the CORBA Messaging Spec a legal IDL can lead to an illegal implied-IDL. A possible correction could be to - map operations and attributes to implied-IDL operations and attributes starting with '_sendc_', '_sendp_', etc. - define the language mapping for implied-IDL names starting with '_' This would also allow to get rid of the "ami_" string insertions. Resolution: Revised Text: Actions taken: November 19, 1999: received issue May 13, 2002: closed issue Discussion: First of all, it is not clear at all how A::sendp_op clashes with B::sendp_op. Clearly the fully qualified names are different. According to the first paragraph of section 22.6.1 the name munging rule for sendc is: "The interface’s operations and attributes are mapped to implied-IDL operations with names prefixed by “sendc_”. If this implied-IDL operation name conflicts with existing operations on the interface or any of the interface’s base interfaces, “ami_” strings are inserted between “sendc_” and the original operation name until the implied-IDL operation name is unique." and similarly in section 22.6.2 the name munging rule for sendp is: "The interface’s operations and attributes are mapped to implied-IDL operations with names prefixed by sendp_. If this implied-IDL operation name conflicts with existing operations on the interface or any of the interface’s base interfaces, ami_ strings are inserted between sendp_ and the original operation name until the implied-IDL operation name is unique." Since both these rules say that you keep inserting "ami_" until you get an unique name, given that any interfcace has a finite number of methods with names that are already known when the munged names are computed, it is not clear under what circumstances one would get invalid IDL. End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 19 Nov 1999 11:25:13 +0100 Message-Id: Subject: messaging issues: name clashes from implied IDL MIME-Version: 1.0 TO: issues@omg.org, messaging-rtf@omg.org CC: sgw@adnovum.com Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 19 Nov 1999 11:25:13 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 19 Nov 1999 11:25:13 +0100" X-UIDL: lcY!!3DW!!-b*e9QK$!! Hi I would like to raise the following issue with Messaging: The name conflict resolution algorithm for implied-IDL operations and attributes (based on inserting "_ami" strings) does not cover all possible name conflicts. Example: // IDL interface A { void op (); }; interface B { void sendp_op() }; The implied-IDL operation A::sendp_op conflicts with B::sendp_op. -> Thus, according to the CORBA Messaging Spec a legal IDL can lead to an illegal implied-IDL. A possible correction could be to - map operations and attributes to implied-IDL operations and attributes starting with '_sendc_', '_sendp_', etc. - define the language mapping for implied-IDL names starting with '_' This would also allow to get rid of the "ami_" string insertions. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax Date: Thu, 20 Dec 2001 15:51:14 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard Company X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: orb_revision@omg.org Subject: Proposed resolution for 3054 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id fBKKfdM22042 Content-Type: text/plain; charset=iso-8859-1 X-UIDL: Imnd9#@\d9Ik9!!T`F!! The proposed resolution will appear in a vote around the second week of January unless there is significant technical objection to it. Jishnu. _________________________________________________________________ Issue 3054: messaging issues: name clashes from implied IDL (messaging-rtf) Click here for this issue's archive. Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl@ubs.com ) Nature: Uncategorized Issue Severity: Summary: The name conflict resolution algorithm for implied-IDL operations and attributes (based on inserting "_ami" strings) does not cover all possible name conflicts. Example: // IDL interface A { void op (); }; interface B { void sendp_op() }; The implied-IDL operation A::sendp_op conflicts with B::sendp_op. -> Thus, according to the CORBA Messaging Spec a legal IDL can lead to an illegal implied-IDL. A possible correction could be to - map operations and attributes to implied-IDL operations and attributes starting with '_sendc'_. If this implied-IDL operation name conflicts with existing operatiosn strings are inserted between on the interface or any of the interface, '_sendp_', etc. - define the language mapping for implied-IDL names starting with '_' This would also allow to get rid of the "ami_" string insertions. Resolution: First of all, it is not clear at all how A::sendp_op clashes with B::sendp_op. Clearly the fully qualified names are different. According to the first paragraph of section 22.6.1 the name munging rule for send c and the original operation name until the implied-IDL operation name is unique." and similarly in section 22.6.2 the name munging rule for sendp is: "The interface is: "The interface