Issue 18533: IDL2C++11 issue : CORBA dependency of the C++11 mapping (idl2cpp11-rtf) Source: PrismTech (Nawel Hamouche, nawel.hamouche(at)prismtech.com) Nature: Uncategorized Issue Severity: Summary: A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException. Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 “Semantics of Abstract Interfaces” for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA. I would suggest the following changes in the IDL2CPP11 specification : - To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException. - To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly. - To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly. - To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include : 6.16 Mapping for the Any Type 6.17 Mapping for Valuetypes 6.18.1 Abstract Interface Base 6.21 TypeCode 6.22 ORB 6.23 Object 6.24 LocalObject ... until 6.28 Resolution: The IDLC++11 langauge mapping explicitly refers to CORBA v3.2 because there is no clean IDL spec yet. There should first be a clean IDL4 spec that is completely middleware agnostic and which gives generic guidelines for language mappings how to target specific middleware technologies like CORBA. At the moment there is an IDL4 spec with those guidelines we can update the IDL2C++11 spec accordingly June 11, 2013 41 Disposition: Deferred Revised Text: Actions taken: March 7, 2013: received issue Discussion: End of Annotations:===== ogle-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=Zam02TTRcWJZD/0zxklbLlCWnBYlgF7nMUbU4I0bluI=; b=bdLdP1iti9LKVj8iCNcEpjrq1aJjoyWNEtFVXbegn7QG1BMC0cXBQgKiW4URmld7Cd t8kpVx3Uh6VSpuzIrWMM0IHcDG1BwXrgFLgzXJZIwIMPfUyJX4E+oTDL0KdAh3FRF6cM Ev0CBDZmAyXuopI5beJm5DY9DTgqD+/qa4bNV9buunF7Ub2HUQxVXvozeGVMfwkirny8 8niuWvlJam8wAvPkapb0iSOHlU1ZtZPvQPZwCXouHPrOYxzwDclO0iOrB2wWB62HPFi5 5GxVDhYI0hsSr9AZFBOl0M4K4XJT8De7ATJ68YgeFI+zgmphyOsKn5lLTOV/NdDcij7R 0FlA== X-Received: by 10.194.91.211 with SMTP id cg19mr55136773wjb.43.1362667806606; Thu, 07 Mar 2013 06:50:06 -0800 (PST) Date: Thu, 07 Mar 2013 15:50:36 +0100 From: Nawel Hamouche User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120623 Thunderbird/10.0.5 To: issues@omg.org Subject: IDL2C++11 issue : CORBA dependency of the C++11 mapping X-Gm-Message-State: ALoCoQnB4E807jA82wcXHdDuBc79TXw20BCAzDLccKMSANJEIODGh5xI9NW5nw8CP1ctv6L25xPM X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAR0ZpzU= X-Brightmail-Tracker: AAAAAA== Hello, A big effort have been done to remove CORBA dependency from the IDL2C++11 mapping, but it still specifies a CORBA semantic to the IDL interfaces and user exceptions. In 6.6.4, it is said "Conceptually, the Object class in the CORBA module is the base interface type for all objects;" this assertion breaks all that efforts. I think the semantic of IDL interfaces should be abstracted by defining a middleware-independent Object type as the super type of all IDL interfaces, it could be IDL::Object. Likewise, CORBA::UserException and CORBA::SystemException could be abstracted by defining IDL::UserExeption and IDL::SystemException. Looking to the IDL3.5 specification, it is true that this specification is still tied to CORBA, but special care has been done to separate between the syntactical construct and its semantic. For instance, it is said 'See the CORBA 3.2 specfication Section 10.2 .Semantics of Abstract Interfaces. for CORBA implementation semantics associated with abstract interfaces.'. It means that there could be other semantics than CORBA. I would suggest the following changes in the IDL2CPP11 specification : - To introduce IDL::Object, IDL::LocalObject, IDL::UserExeption and IDL::SystemException. - To not consider an IDL interface as a CORBA Object and rephrase section 6.6.4 accordingly. - To not consider a user exception as a CORBA exeption and rephrase section 6.19 accordingly. - To group all CORBA-dependent mappings and APIs in one section "CORBA mapping". This section would include : 6.16 Mapping for the Any Type 6.17 Mapping for Valuetypes 6.18.1 Abstract Interface Base 6.21 TypeCode 6.22 ORB 6.23 Object 6.24 LocalObject ... until 6.28 Best Regards, Nawel -- Nawel HAMOUCHE Senior Engineer PrismTech FRANCE nawel.hamouche@prismtech.com +33 (0)1 69 01 53 54 PrismTech is a global leader in standards-based, performance-critical middleware. Our products enable our OEM, Systems Integrator, and End User customers to build and optimize high-performance systems primarily for Mil/Aero, Communications, Industrial, and Financial Markets. From: BECU Didier To: "idl2cpp11-rtf@omg.org" Date: Thu, 7 Mar 2013 16:32:52 +0100 Subject: CORBA dependency of the IDL2C++11 mapping in the business code Thread-Topic: CORBA dependency of the IDL2C++11 mapping in the business code Thread-Index: Ac4bSLzEkoeRguCNRBqwVoHNo00l5A== Accept-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.0.0, Antivirus-Engine: 3.40.1, Antivirus-Data: 4.86G X-Virus-Scanned: amavisd-new at omg.org X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id r27FarGB003160 X-Brightmail-Tracker: AAAAAR0ZpzU= X-Brightmail-Tracker: AAAAAA== Dear all, In the business code, some concepts as interface, exception, ... must be independent of the technology used in the communications as Corba, DDS, .... whatever the used technology, the business code does not be changed. The entities dependent of the communication technology as Corba for exemple will be only used and found in the different connectors, not in the components So as the data types, "interface", "exception", and perhaps other entities must be mapped on native types according to the used language as C++ or Java for example idl interface is mapped on abstract class and inherit from a generic abstract class in C++ or is mapped on interface and inherit from a generic interface in java Perhaps this problem will be taken into account in the planned "refactoring" of the IDL standard What do you think about this ? Best regards Didier Didier BĂ© Thales Com SC2 Palaiseau X-Virus-Scanned: by XS4ALL Virus Scanner Date: Thu, 07 Mar 2013 16:55:42 +0100 From: Johnny Willemsen Reply-To: jwillemsen@remedy.nl Organization: Remedy IT User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 To: BECU Didier CC: Nawel Hamouche , idl2cpp11-rtf@omg.org Subject: Re: CORBA dependency of the IDL2C++11 mapping in the business code X-Virus-Scanned: amavisd-new at omg.org X-Brightmail-Tracker: AAAAAA== X-Brightmail-Tracker: AAAAAA== Hi, In the business code, some concepts as interface, exception, ... must be independent of the technology used in the communications as Corba, DDS, .... whatever the used technology, the business code does not be changed. The entities dependent of the communication technology as Corba for exemple will be only used and found in the different connectors, not in the components Yes, we agree with this. So as the data types, "interface", "exception", and perhaps other entities must be mapped on native types according to the used language as C++ or Java for example idl interface is mapped on abstract class and inherit from a generic abstract class in C++ or is mapped on interface and inherit from a generic interface in java Perhaps this problem will be taken into account in the planned "refactoring" of the IDL standard What do you think about this ? We agree that this *must* be done as part of the clean separation of IDL into its own specification. Also there are some more ideas discussed in the past about extending/improving IDL as part of a new IDL4 revision. The IDL2C++11 language mapping explicitly refers to CORBA v3.2 because there is no formal IDL3.5 version available. A beta 1 IDL35 specification was just published and this doesn't have a full clean separation yet and also CORBA hasn't been updated yet to be based on the new IDL spec. For example a local interface is still derived from a unconstrained interface, it should be switched, or introduce something like IDL::Object I think this is related to the new issue 18533. We also want to go into that direction, but to our idea first the IDL3.5/4 spec should be finished with these additional constraints in memory, than we can update the IDL2C++11 spec to address this issue. Independent of that, given the usage of IDL::traits<> in the spec an implementation of IDL2C++11 can shield this already for the user and let it be an implementation detail. In the CCM/UCM implementation work we have done with C++11 the user just doesn't see anything of CORBA::Object in its business code at all, with the current mapping as it is now. He just uses IDL::traits::ref_type. Let us discuss this also in person at the OMG Reston meeting, as far as I know Nawel will also be there. Regards, Johnny