Issue 5910: issue on component supporting abstract interfaces (components-ftf) Source: Laboratoire d`Informatique Fondamentale de Lille (Mr. Raphael G. Marvie, nobody) Nature: Uncategorized Issue Severity: Summary: The following information is sent in order for the specification to clearly state if components and local interfaces can support abstract interfaces (the specification is confusing on this point). CORBA 3.0.1 does not explicitely states if a component can support an abstract interface, thus it can be considered that it is possible. If so a big problem arises as local interfaces inheriting abstract ones is confusing in the specification. In addition, it is neither explicitely stated that provides and uses declarations can or cannot be of types defined through abstract interfaces. It does not seem to make sense for a port to be an abstract type. Facets will never be used by value, and an operation cannot (should not) return the reference of a facet or a valuetype (which would be in favor of provides to be defined using abstract interfaces). ** Problem Consider the following definitions which are correct regarding formal/02-12-06: /* omg idl3 */ abstract interface I { void foo () ; } ; component C supports I { } ; The mapping to OMG IDL2 of these definitions is not correct right now as they become: /* omg idl2 */ abstract interface I { void foo () ; } ; interface C : Components::CCMObject, I { } ; local interface CCM_C : I { } ; According to formal/02-12-06, the last line may not be correct. Local interfaces may not inherit abstract interfaces (section 10.5.28). (I use may as it is confusing and can lead to various understanding of the spec.) ** Potential solutions: 1. State in the CORBA 3.0.1 that components cannot support abstract interfaces. In favor: Could ne considered as a minor change. Against: a component reference cannot be returned by an operation that can return an object by value or by reference. This solution looks cleaner that the second one from a software engineering point of view. 2. Clearly state that components and local interfaces can support abstract interfaces. This use may be surprising from a software engineering point of view, but may be important for some users. This bring back the debate "quality vs powerfulness". In any case, I think it should be clearly stated if local interfaces may or may not inherit abstract ones. Resolution: Revised Text: Actions taken: April 23, 2003: received issue Discussion: End of Annotations:===== Subject: Issue about abstract interface inheritence From: Raphael Marvie Reply-To: raphael.marvie@lifl.fr To: issues@omg.org Cc: Juergen Boldt , marvie@lifl.fr Organization: LIFL (France) X-Mailer: Ximian Evolution 1.2.1- Date: 23 Apr 2003 14:32:52 +0200 X-MailScanner: Found to be clean issue on component supporting abstract interfaces. The following information is sent in order for the specification to clearly state if components and local interfaces can support abstract interfaces (the specification is confusing on this point). CORBA 3.0.1 does not explicitely states if a component can support an abstract interface, thus it can be considered that it is possible. If so a big problem arises as local interfaces inheriting abstract ones is confusing in the specification. In addition, it is neither explicitely stated that provides and uses declarations can or cannot be of types defined through abstract interfaces. It does not seem to make sense for a port to be an abstract type. Facets will never be used by value, and an operation cannot (should not) return the reference of a facet or a valuetype (which would be in favor of provides to be defined using abstract interfaces). ** Problem Consider the following definitions which are correct regarding formal/02-12-06: /* omg idl3 */ abstract interface I { void foo () ; } ; component C supports I { } ; The mapping to OMG IDL2 of these definitions is not correct right now as they become: /* omg idl2 */ abstract interface I { void foo () ; } ; interface C : Components::CCMObject, I { } ; local interface CCM_C : I { } ; According to formal/02-12-06, the last line may not be correct. Local interfaces may not inherit abstract interfaces (section 10.5.28). (I use may as it is confusing and can lead to various understanding of the spec.) ** Potential solutions: 1. State in the CORBA 3.0.1 that components cannot support abstract interfaces. In favor: Could ne considered as a minor change. Against: a component reference cannot be returned by an operation that can return an object by value or by reference. This solution looks cleaner that the second one from a software engineering point of view. 2. Clearly state that components and local interfaces can support abstract interfaces. This use may be surprising from a software engineering point of view, but may be important for some users. This bring back the debate "quality vs powerfulness". In any case, I think it should be clearly stated if local interfaces may or may not inherit abstract ones. -- Raphael Marvie - PhD Research Scientist @ LIFL (France) http://www.lifl.fr/~marvie "Don't blame me, I am deprecated" From: mathieu.vadet@fr.thalesgroup.com To: juergen@omg.org Subject: RE: issue 5910 -- Components RTF issue Date: Fri, 25 Apr 2003 10:13:56 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h3P8ck8i011024 Hi, Although I agree on the two following facts: 1) it seems strange from a software engineering point of view to have a component inheriting from an abstract interface 2) the section 10.5.28 of formal/02-12-06 is not clearly stating that a local interface may inherit from an asbtract interface In formal/02-12-06, section 3.8.7, it is said: "An interface declaration not containing the keyword local is referred to as an unconstrained interface. .... The following special rules apply to local interfaces: * A local interface may inherit from other local or unconstrained interfaces. * ... * a valuetype may support a local interface * ..." To my understanding, it clearly states that a local interface may inherit from an abstract interface. Therefore, 1) the OMG IDL mapping for the example given is correct 2) potential solution 1. given below is correct, but in addition, it shall be more clearly stated in section 10.5.28 (and also 10.5.29) that local interfaces may have as base interfaces AbstractInterfaceDefs (and also ExtAbstractInterfaceDefs in 10.5.29) regards, Mathieu > > This is issue #5910 Raphael Marvie > > > > issue on component supporting abstract interfaces > > The following information is sent in order for the specification to > clearly state if components and local interfaces can support abstract > interfaces (the specification is confusing on this point). > > > CORBA 3.0.1 does not explicitely states if a component can support an > abstract interface, thus it can be considered that it is > possible. If so > a big problem arises as local interfaces inheriting abstract ones is > confusing in the specification. > > > In addition, it is neither explicitely stated that provides and uses > declarations can or cannot be of types defined through abstract > interfaces. It does not seem to make sense for a port to be > an abstract > type. Facets will never be used by value, and an operation cannot > (should not) return the reference of a facet or a valuetype > (which would > be in favor of provides to be defined using abstract interfaces). > > > ** Problem > > > Consider the following definitions which are correct regarding > formal/02-12-06: > > > /* omg idl3 */ > > > abstract interface I { void foo () ; } ; > > > component C supports I { > } ; > > > The mapping to OMG IDL2 of these definitions is not correct > right now as > they become: > > > /* omg idl2 */ > > > abstract interface I { void foo () ; } ; > > > interface C : Components::CCMObject, I { } ; > > > local interface CCM_C : I { } ; > > > According to formal/02-12-06, the last line may not be correct. Local > interfaces may not inherit abstract interfaces (section > 10.5.28). (I use > may as it is confusing and can lead to various understanding of the > spec.) > > > ** Potential solutions: > > > 1. State in the CORBA 3.0.1 that components cannot support abstract > interfaces. In favor: Could ne considered as a minor change. > Against: a > component reference cannot be returned by an operation that can return > an object by value or by reference. This solution looks > cleaner that the > second one from a software engineering point of view. > > > 2. Clearly state that components and local interfaces can support > abstract interfaces. This use may be surprising from a software > engineering point of view, but may be important for some users. This > bring back the debate "quality vs powerfulness". > > > > In any case, I think it should be clearly stated if local > interfaces may > or may not inherit abstract ones. > > > ================================= > J|rgen Boldt > Director, Member Services > > Object Management Group > 250 First Avenue, Suite 100 > Needham, MA 02494 > > Tel. +1 781 444 0404 ext. 132 > Fax: +1 781 444 0320 > email: juergen@omg.org > www www.omg.org > > ================================ ------------------------------------------------------------------------ ---------------- Mathieu Vadet - PhD Student, GOAL Team, LIFL CIFRE at THALES Communications, SC2 Department Address: THALES Communications 1-5, Avenue Carnot / BC4 91883 Massy Cedex, France Tel: (33) (0)1 69 75 35 37 E-Mail: mailto:mathieu.vadet@fr.thalesgroup.com See also: http://www.objectweb.org/openccm/ ------------------------------------------------------------------------ ----------------