Issue 456: Interpretation of _narrow semantics (cxx_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: Section 16.3.4: Question on how to use _narrow with C++ bindings. Should D::_narrow work? Does answer depend on interpretation of "actual (run-time) type"? Resolution: fixed, close issue Revised Text: Actions taken: November 16, 1996: received issue February 23, 1999: issue closed Discussion: End of Annotations:===== This is issue # 456 Interpretation of _narrow semantics Section 16.3.4: Question on how to use _narrow with C++ bindings. Should D::_narrow work? Does answer depend on interpretation of "actual (run-time) type"? -Juergen From newcombe@austin.ibm.com Fri Nov 15 19:17:59 1996 Received: from netmail.austin.ibm.com by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA10029; Fri, 15 Nov 1996 19:17:59 -0500 Received: from socks.austin.ibm.com (socks.austin.ibm.com [129.35.251.68]) by netmail.austin.ibm.com (8.6.12/8.6.11) with SMTP id SAA45000; Fri, 15 Nov 1996 18:14:48 -0600 Received: from localhost.austin.ibm.com by socks.austin.ibm.com (AIX 4.1/UCB 5.64/4.03-client-2.6) for newcombe@austin.ibm.com at austin.ibm.com; id AA48118; Fri, 15 Nov 1996 18:14:46 -0600 Sender: newcombe@austin.ibm.com Message-Id: <328D0775.167E@austin.ibm.com> Date: Sat, 16 Nov 1996 00:14:45 +0000 From: "Russell L. Newcombe" Organization: IBM ORB/Object Services Technology X-Mailer: Mozilla 3.0 (X11; I; AIX 2) Mime-Version: 1.0 To: orbos@omg.org, cxx_revision@omg.org Cc: "Rob High Jr." , Liane Acker , Scott Danforth , Virgil Albaugh , Phil Chang Subject: Interpretation of _narrow semantics Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We have a question related to the use of _narrow with C++ bindings (as defined in section 16.3.4). I will define the situation and then ask the question. The following example appears at the end of that section: Interface types having inheritance relationships as follow: A / \ D B | C An object of type C is passed to a function as an A. The example states that both B::_narrow and C::_narrow work (because the object is a B and is a C), but that D::_narrow does not work (because the object is not a D). Let's modify this to now say an object of type C is passed to a function as a B. Similarly, C::_narrow would work and D::_narrow would not work. Now lets take the example one step further, and add an interface of type E that inherits from both D and C, like this: A / \ D B \ | \ C \| E An object of type E is passed to a function as a B. Let's also assume that the process only contains usage bindings for A, B, C and D but does not contain usage bindings for E. The question is, should D::_narrow work? Section 16.3.4 states "If the actual (run-time) type of the parameter object can be widened to the requested interface's type, then _narrow will return a valid object reference." I think the answer may depend upon your interpretation of "actual (run-time) type". Is the run-time type E because that is what the implementation object supports, and therefore D::_narrow works. Does the fact that no E usage bindings exist on the client preclude it from being an E,and therefore D::_narrow doesn't work. I would appreciate hearing any opinions on how this should be interpreted (what was the intention) and also how different ORBs actually implement this. Thanks, Russ -- ---------------------------------------------------------------------- - Russ Newcombe IBM Corp. - ORB/Object Services Technology MS 9640 - newcombe@austin.ibm.com 11400 Burnet Road - (512) 838-0411 Austin, TX 78758-3407 - (512) 838-1032 fax U.S.A. ---------------------------------------------------------------------- From prasad@visigenic.com Fri Nov 15 19:39:03 1996 Received: from odin.visigenic.com by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA10173; Fri, 15 Nov 1996 19:39:03 -0500 Received: from escher ([206.64.15.29]) by odin.visigenic.com (Netscape Mail Server v2.0) with SMTP id AAA4501; Fri, 15 Nov 1996 16:34:42 -0700 Sender: "Prasad Mokkapati" Message-Id: <328D0C05.131D@visigenic.com> Date: Fri, 15 Nov 1996 16:34:13 -0800 From: Prasad Mokkapati Organization: Visigenic Software Inc X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4u) Mime-Version: 1.0 To: "Russell L. Newcombe" Cc: orbos@omg.org, cxx_revision@omg.org, "Rob High Jr." , Liane Acker , Scott Danforth , Virgil Albaugh , Phil Chang Subject: Re: Interpretation of _narrow semantics References: <328D0775.167E@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Russell L. Newcombe wrote: > > We have a question related to the use of _narrow with C++ bindings (as > defined in section 16.3.4). I will define the situation and then ask the > question. The following example appears at the end of that section: > > Interface types having inheritance relationships as follow: > > A > / \ > D B > | > C > > An object of type C is passed to a function as an A. The example states > that both B::_narrow and C::_narrow work (because the object is a B and > is a C), but that D::_narrow does not work (because the object is not a > D). > > Let's modify this to now say an object of type C is passed to a function > as a B. Similarly, C::_narrow would work and D::_narrow would not work. > > Now lets take the example one step further, and add an interface of type > E that inherits from both D and C, like this: > > A > / \ > D B > \ | > \ C > \| > E > > An object of type E is passed to a function as a B. Let's also assume > that the process only contains usage bindings for A, B, C and D but does > not contain usage bindings for E. > > The question is, should D::_narrow work? > > Section 16.3.4 states "If the actual (run-time) type of the parameter > object can be widened to the requested interface's type, then _narrow > will return a valid object reference." I think the answer may depend > upon your interpretation of "actual (run-time) type". In our implementation (VisiBroker for C++) this works. > > Is the run-time type E because that is what the implementation object > supports, and therefore D::_narrow works. > > Does the fact that no E usage bindings exist on the client preclude it > from being an E,and therefore D::_narrow doesn't work. > > I would appreciate hearing any opinions on how this should be > interpreted (what was the intention) and also how different ORBs > actually implement this. > > In our C++ implementation, we check locally to see if the cast (_narrow) is valid. If it fails, "_is_a" method on CORBA::Object is invoked (remote call) to determine if the cast (to D) is valid. If it succeeds, the appropriate stub - D is created and returned from _narrow call. Regards, Prasad From jon@sems.com Fri Nov 15 20:26:46 1996 Received: from ns.sems.com by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA10452; Fri, 15 Nov 1996 20:26:46 -0500 Received: from vaccine-bb.netlabs.com ([192.190.199.1]) by proxy.netlabs.com (4.1/SMI-4.1) id AA19354; Fri, 15 Nov 96 16:19:05 PST Received: from clamp.netlabs.com by vaccine-bb.netlabs.com (4.1/SMI-4.1) id AA01113; Fri, 15 Nov 96 17:25:39 PST Received: from clamp by clamp.netlabs.com (SMI-8.6/SMI-SVR4) id RAA08147; Fri, 15 Nov 1996 17:25:42 -0800 Sender: jon@sems.com Message-Id: <328D1814.54E9@sems.com> Date: Fri, 15 Nov 1996 17:25:40 -0800 From: Jonathan Biggar Organization: Seagate Enterprise Management Software X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: "Russell L. Newcombe" Cc: orbos@omg.org, cxx_revision@omg.org, "Rob High Jr." , Liane Acker , Scott Danforth , Virgil Albaugh , Phil Chang Subject: Re: Interpretation of _narrow semantics References: <328D0775.167E@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The narrow to D should work correctly. As an implementation note, D::_narrow() should first try to use the static information contained in the generated C++ classes to perform the narrow (if you are using C++ inheritence to implement IDL inheritence). If that fails because the runtime type of the object is unknown by the client, then D::_narrow() should fall back internally to calling Object::is_a("D"). If this succeeds, then the narrow should succeed also. Jon Biggar Russell L. Newcombe wrote: > > We have a question related to the use of _narrow with C++ bindings (as > defined in section 16.3.4). I will define the situation and then ask the > question. The following example appears at the end of that section: > > Interface types having inheritance relationships as follow: > > A > / \ > D B > | > C > > An object of type C is passed to a function as an A. The example states > that both B::_narrow and C::_narrow work (because the object is a B and > is a C), but that D::_narrow does not work (because the object is not a > D). > > Let's modify this to now say an object of type C is passed to a function > as a B. Similarly, C::_narrow would work and D::_narrow would not work. > > Now lets take the example one step further, and add an interface of type > E that inherits from both D and C, like this: > > A > / \ > D B > \ | > \ C > \| > E > > An object of type E is passed to a function as a B. Let's also assume > that the process only contains usage bindings for A, B, C and D but does > not contain usage bindings for E. > > The question is, should D::_narrow work? > > Section 16.3.4 states "If the actual (run-time) type of the parameter > object can be widened to the requested interface's type, then _narrow > will return a valid object reference." I think the answer may depend > upon your interpretation of "actual (run-time) type". > > Is the run-time type E because that is what the implementation object > supports, and therefore D::_narrow works. > > Does the fact that no E usage bindings exist on the client preclude it > from being an E,and therefore D::_narrow doesn't work. > > I would appreciate hearing any opinions on how this should be > interpreted (what was the intention) and also how different ORBs > actually implement this. > > Thanks, > Russ > > -- > ---------------------------------------------------------------------- > - Russ Newcombe IBM Corp. > - ORB/Object Services Technology MS 9640 > - newcombe@austin.ibm.com 11400 Burnet Road > - (512) 838-0411 Austin, TX 78758-3407 > - (512) 838-1032 fax U.S.A. > ---------------------------------------------------------------------- From vinoski@apollo.hp.com Tue Dec 10 14:38:52 1996 Received: from palrel3.hp.com by amethyst.omg.org (5.4R2.01/1.34) id AA28349; Tue, 10 Dec 1996 14:38:52 -0500 Received: from amway.ch.apollo.hp.com (daemon@amway.ch.apollo.hp.com [15.254.24.2]) by palrel3.hp.com with SMTP (8.7.5/8.7.3) id LAA05564; Tue, 10 Dec 1996 11:35:42 -0800 (PST) Received: from nis_mstr.ch.apollo.hp.com by amway.ch.apollo.hp.com id Tue, 10 Dec 1996 14:35:40 -0500 Received: from earl.ch.apollo.hp.com by nis_mstr.ch.apollo.hp.com id AA034846539; Tue, 10 Dec 1996 14:35:40 -0500 Message-Id: <3.0.32.19961210143530.006c65e0@pop-e3.ch.apollo.hp.com> X-Sender: vinoski@pop-e3.ch.apollo.hp.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 10 Dec 1996 14:35:31 -0500 To: juergen@omg.org From: Steve Vinoski Subject: Re: issue456 Cc: cxx_revision@omg.org, issues@omg.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:25 PM 12/10/96 -0700, juergen@omg.org wrote: >This is issue # 456 May I ask why issues that were already addressed and resolved by the C++ 1.1 RTF are continually being fed into the issues database? I can't remember of the one below qualifies as an issue that was already closed or not, but I have seen a number of issues go by over the past few weeks that we definitely closed over a year ago. --steve > >Interpretation of _narrow semantics > >Section 16.3.4: Question on how to use _narrow with C++ bindings. > Should D::_narrow work? Does answer depend on interpretation of > "actual (run-time) type"? > > >-Juergen >