Issue 3059: messaging issue: unchecked narrow too constrained (messaging-rtf) Source: UBS (Mr. Hans Kneubuehl, hans.kneubuehl(at)ubs.com) Nature: Uncategorized Issue Severity: Summary: The semantics of unchecked narrow are defined more constrained than actually needed. The specification states that the _unchecked_narrow operation always returns a valid object reference. I think this should be loosened such that it is permitted that a nil object reference is returned even if the parameter to _unchecked_narrow is not the nil object reference. Resolution: Change text as described below Revised Text: Change the following text in section3.3.7 Note on Asynchrony and Narrowing of Object References "Many programming languages map IDL interfaces to programming construct that support inheritance. In those language mappings (such as C++ and Java) that provide a mechanism for narrowing an Object reference of a base interface to a more derived interface, the act of narrowing may require the full type hierarchy of the target. In this case, the implementation of narrow must either contact an interface repository or the target itself to determine whether or not it is safe to narrow the client?s object reference. This requirement is not acceptable when a client is expecting only asynchronous communication with the target. Therefore, for the appropriate languages this specification adds an unchecked narrow operation to the IDL mappings for interface. This unchecked narrow always returns a stub of the requested type without checking that the target really implements that interface. If a client narrows the target to an unsupported interface type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION." to Many programming languages map IDL interfaces to programming constructs that support inheritance. In those language mappings (such as C++ and Java) that provide a mechanism for narrowing an Object reference of a base interface to a more derived interface, the act of narrowing may require the full type hierarchy of the target. In this case, some implementations of narrow might require either to contact an interface repository or the target itself to determine whether or not it is safe to narrow the client?s object reference. This requirement is not acceptable when a client is expecting ony asynchronous communication with the target. Therefore, for the appropriate languages this specification adds an unchecked narrow operation to the IDL mappings for interface. In cases where a safe narrow requires remote communication, this unchecked narrow always returns a stub of the requested type without checking that the target really implements that interface. Because some implementations might be capable to detect a narrowing failure completely locally, compliant applications must be prepared that unchecked narrow may return nil for a non-nil object reference. However, note that in case of interoperability with another ORB, the client must no fail to narrow the reference without consulting the target via the "is_a" or "_get_interface" pseudo-operations (see CORBA 2.3, 13.6.2). If a client narrows the target to an unsupported interface type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION." Similarly, in section 9.2.5.1 replace the following text "Unlike the _narrow function, _unchecked_narrow does not perform any verification that the actual (runtime) type of the parameter object can be widened to the requested Iinterface's type. This function always returns a valid object reference." with "Unlike the _narrow function, _unchecked_narrow does not perform any remote communication in order to verify that the actual (runtime) type of the parameter object can be widened to the requested interface's type. In cases where a safe narrow requires remote communcation, this function always returns a valid object reference. However, note that compliant applications must be prepared that _unchecked_narrow may return nil for a non-nil object reference." Similarly, in section 9.2.5.4 change the following text from "The helper class holds a static unchecked_narrow method that allows a "org.omg.CORBA.Object" to be narrowed to the object reference of a more specific type. No type-checking is performed to verify that the object actually supports the requested type. The IDL exception "CORBA::BAD_OPERATION" can be expected if unsupported operations are invoked on the new returned reference, but no failure is indicated at the time of the unchecked_narrow." to "The helper class holds a static unchecked_narrow method that allows a "org.omg.CORBA.Object" to be narrowed to the object reference of a more specific type. No type-checking which requires remote communication is performed to verify that the object actually supports the requested type. The IDL exception "CORBA::BAD_OPERATION" can be expected if unsupported operations are invoked on the new returned reference. Compliant applications still must expect that a failure is indicated by the exception "CORBA::BAD_PARAM" at the time of the unchecked_narrow." Actions taken: November 25, 1999: received issue October 4, 2000: closed issue Discussion: Since the proposed resolution to this issue failed in the last RTF, it is pretty clear people dont want to do this. Therefore this issue should be closed. End of Annotations:===== From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Thu, 25 Nov 1999 16:40:56 +0100 Message-Id: Subject: messaging issue: unchecked narrow too constrained MIME-Version: 1.0 TO: issues@omg.org, messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Thu, 25 Nov 1999 16:40:56 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Thu, 25 Nov 1999 16:40:56 +0100" X-UIDL: O)3e9j\m!!m>-!!Zf+e9 Hi I would like to raise the following issue with Messaging: The semantics of unchecked narrow are defined more constrained than actually needed. The specification states that the _unchecked_narrow operation always returns a valid object reference. I think this should be loosened such that it is permitted that a nil object reference is returned even if the parameter to _unchecked_narrow is not the nil object reference. The reason is that certain ORB implementations might have the means to do some limited local validity checking (without depending on a remote system). This could be done based on ORB proprietary type information in the IOR, e.g. an ORB might detect from proprietary version info that there is no chance that a version 3.0 interface is supported by a version 2.0 runtime interface. To the applications it could be an advantage if unsupported interfaces are detected earlier than after invoking an unsupported operation. Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 Sender: Chris.Smith@uab.ericsson.se Message-ID: <383FC7BE.9351DBD5@uab.ericsson.se> Date: Sat, 27 Nov 1999 12:59:58 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: messaging issue: unchecked narrow too constrained References: Content-Type: multipart/mixed; boundary="------------E1ADC45D98B51BE6FE61894E" X-UIDL: 5g~e9~iWd9?Hld9"^=!! Hi Hans, I understand the intention of your message, but there are several problems with doing this. > The semantics of unchecked narrow are defined more constrained than actually > needed. > > The specification states that the _unchecked_narrow operation always returns a > valid object reference. I think this should be loosened such that it is > permitted that a nil object reference is returned even if the parameter to > _unchecked_narrow is not the nil object reference. What you are trying to say here is that an implementation of _unchecked_narrow should be allowed to fail if it can be sure that the type will not pass the _is_a test, as long as it does not make a remote invocation. The problems with this are : 1) Returning nil is the behaviour that C++ has for failing a narrow test. However, in Java, the BAD_PARAM exception is thrown. This is however, a small problem. 2) The CORBA specification says that an implementation must NOT fail to narrow without calling _is_a() on the remote object. I think this "directive" applies to the concept ofnarrowing in general and not just the old narrow. This would clearly be in contravention of your proposal. It can of course succeed in narrowing without calling _is_a() and _unchecked_narrow() is an extension of this. 3) Since normal narrowing implies a YES answer to _is_a(), and since _is_a() is (these days) possible to be overridden by the remote object, there is no way proprietary information in an IOR could know what the application might answer to _is_a(). This is the reason (I believe) for the directive mentioned in 2) above. We can argue over whether letting applications override _is_a() was a good idea, but its a fact of life now, so we might as well live with it. > > The reason is that certain ORB implementations might have the means > to do some > limited local validity checking (without depending on a remote > system). This > could be done based on ORB proprietary type information in the IOR, > e.g. an ORB > might detect from proprietary version info that there is no chance > that a > version 3.0 interface is supported by a version 2.0 runtime > interface. > > To the applications it could be an advantage if unsupported > interfaces are > detected earlier than after invoking an unsupported operation. I agree that it is advantageous if an unsupported interface can be detected earlier. However, with POA, DSI, and overridden _is_a() one can really never know enough about an object to be able to say definitively from its object reference only that it does NOT support a particular interface. Any other comments from you folks? Chris [] Chris.Smith1.vcf From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Sat, 27 Nov 1999 14:26:54 +0100 Message-Id: Subject: Re: messaging issue: unchecked narrow too constrained -> reference? MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 27 Nov 1999 14:26:54 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Sat, 27 Nov 1999 14:26:54 +0100" X-UIDL: ZO6!!(o:e9H)Fe9%Vk!! Hi Chris Thanks for the pertinent answer. I can follow all your argumentation, however, I'm not sure about the premises it is based on. According to your argumentation, for narrow to fail (return nil) on a valid objref (non-nil), it always has to do a remote call, even if both the type of the objref and the narrowed-to type were known at compile time. Can you give an exact reference to the "directive" you mention in 2), I couldn't find it myself? Regards Hans > -----Original Message----- > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > Sent: Saturday, November 27, 1999 1:00 PM > To: Hans z.h.k.k.8. Kneubuehl > Cc: Chris.Smith; messaging-rtf > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked narrow too > constrained > > > Hi Hans, > I understand the intention of your message, but there > are several > problems > with doing this. > > > The semantics of unchecked narrow are defined more > constrained than actually > > needed. > > > > The specification states that the _unchecked_narrow > operation always returns a > > valid object reference. I think this should be loosened > such that it is > > permitted that a nil object reference is returned even if > the parameter to > > _unchecked_narrow is not the nil object reference. > > > What you are trying to say here is that an implementation of > _unchecked_narrow > should be allowed to fail if it can be sure that the type > will not pass > the > _is_a test, as long as it does not make a remote invocation. > > The problems with this are : > > 1) Returning nil is the behaviour > that C++ has for failing a narrow test. However, in Java, the > BAD_PARAM > exception is thrown. This is however, a small problem. > > 2) The CORBA specification says that an implementation must > NOT fail to narrow without calling _is_a() on the remote object. I > think this "directive" applies to the concept ofnarrowing in general > and not just the old narrow. This would clearly be in > contravention of > your proposal. It can of course succeed in narrowing without calling > _is_a() and _unchecked_narrow() is an extension of this. > > 3) Since normal narrowing implies a YES answer to _is_a(), and since > _is_a() is > (these days) possible to be overridden by the remote object, > there is no > way proprietary information in an IOR could know what the > application > might > answer to _is_a(). This is the reason (I believe) for the directive > mentioned > in 2) above. > > We can argue over whether letting applications override _is_a() was > a > good > idea, but its a fact of life now, so we might as well live with it. > > > > > The reason is that certain ORB implementations might have > the means to do some > > limited local validity checking (without depending on a > remote system). This > > could be done based on ORB proprietary type information in > the IOR, e.g. an ORB > > might detect from proprietary version info that there is no > chance that a > > version 3.0 interface is supported by a version 2.0 runtime > interface. > > > > To the applications it could be an advantage if unsupported > interfaces are > > detected earlier than after invoking an unsupported operation. > > I agree that it is advantageous if an unsupported interface can be > detected > earlier. However, with POA, DSI, and overridden _is_a() one > can really > never > know enough about an object to be able to say definitively from its > object > reference only that it does NOT support a particular interface. > > > Any other comments from you folks? > > Chris > Sender: Chris.Smith@uab.ericsson.se Message-ID: <383FE3F3.DFF73F7@uab.ericsson.se> Date: Sat, 27 Nov 1999 15:00:19 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: messaging issue: unchecked narrow too constrained -> reference? References: Content-Type: multipart/mixed; boundary="------------F5650F8C5194985149B8A498" X-UIDL: j<^d9e#M!!#/gd9GWC!! hans.kneubuehl@ubs.com wrote: > > Hi Chris > > Thanks for the pertinent answer. > > I can follow all your argumentation, however, I'm not sure about the > premises > it is based on. > > According to your argumentation, for narrow to fail (return nil) on > a valid > objref (non-nil), it always has to do a remote call, even if both > the type of > the objref and the narrowed-to type were known at compile time. > > Can you give an exact reference to the "directive" you mention in > 2), I > couldn't find it myself? In section 13.6.2, in the gospel according to OMG, it says The typeId, if provided by the server, indicates the most derived type that the server wishes to publish, at the time the reference is generated. The objects actual most derived type may later change to a more derived type. Therefore the typeId in the IOR can only be interpreted by the client as a hint that the object supports at least the indciated interface. The client can succeed in narrowing the reference to the indicated interface, or to one of its base interfaces, based solely on the type ID in the IOR, but must not fail to narrow the reference without consulting the object via the "is_a" or "_get_interface" pseudo-operations. By "consult the object" I infer actually communicating with it, which therefore cannot be asynchronous. Hence my inference that _unchecked_narrow() cannot fail. > > Regards > Hans > > > -----Original Message----- > > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > > Sent: Saturday, November 27, 1999 1:00 PM > > To: Hans z.h.k.k.8. Kneubuehl > > Cc: Chris.Smith; messaging-rtf > > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked narrow > too > > constrained > > > > > > Hi Hans, > > I understand the intention of your message, but there > > are several > > problems > > with doing this. > > > > > The semantics of unchecked narrow are defined more > > constrained than actually > > > needed. > > > > > > The specification states that the _unchecked_narrow > > operation always returns a > > > valid object reference. I think this should be loosened > > such that it is > > > permitted that a nil object reference is returned even if > > the parameter to > > > _unchecked_narrow is not the nil object reference. > > > > > > What you are trying to say here is that an implementation of > > _unchecked_narrow > > should be allowed to fail if it can be sure that the type > > will not pass > > the > > _is_a test, as long as it does not make a remote invocation. > > > > The problems with this are : > > > > 1) Returning nil is the behaviour > > that C++ has for failing a narrow test. However, in Java, the > > BAD_PARAM > > exception is thrown. This is however, a small problem. > > > > 2) The CORBA specification says that an implementation must > > NOT fail to narrow without calling _is_a() on the remote object. I > > think this "directive" applies to the concept ofnarrowing in > general > > and not just the old narrow. This would clearly be in > > contravention of > > your proposal. It can of course succeed in narrowing without > calling > > _is_a() and _unchecked_narrow() is an extension of this. > > > > 3) Since normal narrowing implies a YES answer to _is_a(), and > since > > _is_a() is > > (these days) possible to be overridden by the remote object, > > there is no > > way proprietary information in an IOR could know what the > application > > might > > answer to _is_a(). This is the reason (I believe) for the > directive > > mentioned > > in 2) above. > > > > We can argue over whether letting applications override _is_a() > was a > > good > > idea, but its a fact of life now, so we might as well live with > it. > > > > > > > > The reason is that certain ORB implementations might have > > the means to do some > > > limited local validity checking (without depending on a > > remote system). This > > > could be done based on ORB proprietary type information in > > the IOR, e.g. an ORB > > > might detect from proprietary version info that there is no > > chance that a > > > version 3.0 interface is supported by a version 2.0 runtime > > interface. > > > > > > To the applications it could be an advantage if unsupported > > interfaces are > > > detected earlier than after invoking an unsupported operation. > > > > I agree that it is advantageous if an unsupported interface can be > > detected > > earlier. However, with POA, DSI, and overridden _is_a() one > > can really > > never > > know enough about an object to be able to say definitively from > its > > object > > reference only that it does NOT support a particular interface. > > > > > > Any other comments from you folks? > > > > Chris > > [] Chris.Smith6.vcf From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Sat, 27 Nov 1999 15:42:28 +0100 Message-Id: Subject: RE: Re: messaging issue: unchecked narrow too constrained -> reference? MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 27 Nov 1999 15:42:28 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Sat, 27 Nov 1999 15:42:28 +0100" X-UIDL: 0#De9A-2e9-$N!!$K-e9 Chris, it says 'without consulting the object VIA the "is_a" or "_get_interface" pseudo-operations' referring to the objref operations. With this statement it's not necessarily saying that _is_a objref implementation must do a remote call in order to fail to narrow. It is saying someting about how the narrowing operation has to be implemented. Of course, the wording is misleading if during narrowing, _is_a fails without actually calling the remote object, but I think the statement is too weak to infere the directive character that you are assigning to it. If this is really the intention, the specs should at least be fixed to define this at a more prominent place, e.g. at the definition of is_a in 4.3.4.1. Additionally, chapter 13 is about ORB interoperability. For communication within the same ORB domain, a vendor is allowed to follow different strategies. > -----Original Message----- > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > Sent: Saturday, November 27, 1999 3:00 PM > To: Hans z.h.k.k.8. Kneubuehl > Cc: Chris.Smith; messaging-rtf > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked narrow too > constrained -> reference? > > > hans.kneubuehl@ubs.com wrote: > > > > Hi Chris > > > > Thanks for the pertinent answer. > > > > I can follow all your argumentation, however, I'm not sure > about the premises > > it is based on. > > > > According to your argumentation, for narrow to fail (return > nil) on a valid > > objref (non-nil), it always has to do a remote call, even > if both the type of > > the objref and the narrowed-to type were known at compile time. > > > > Can you give an exact reference to the "directive" you > mention in 2), I > > couldn't find it myself? > > In section 13.6.2, in the gospel according to OMG, it says > > The typeId, if provided by the server, indicates the most derived > type > that the server wishes to publish, at the time the reference is > generated. The objects actual most derived type may later change to > a > more derived type. Therefore the typeId in the IOR can only be > interpreted by the client as a hint that the object supports at > least > the indciated interface. The client can succeed in narrowing the > reference to the indicated interface, or to one of its base > interfaces, > based solely on the type ID in the IOR, but must not fail to > narrow the > reference without consulting the object via the "is_a" or > "_get_interface" pseudo-operations. > > By "consult the object" I infer actually communicating with it, > which > therefore cannot be asynchronous. Hence my inference that > _unchecked_narrow() cannot fail. > > > > > > Regards > > Hans > > > > > -----Original Message----- > > > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > > > Sent: Saturday, November 27, 1999 1:00 PM > > > To: Hans z.h.k.k.8. Kneubuehl > > > Cc: Chris.Smith; messaging-rtf > > > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked > narrow too > > > constrained > > > > > > > > > Hi Hans, > > > I understand the intention of your message, but there > > > are several > > > problems > > > with doing this. > > > > > > > The semantics of unchecked narrow are defined more > > > constrained than actually > > > > needed. > > > > > > > > The specification states that the _unchecked_narrow > > > operation always returns a > > > > valid object reference. I think this should be loosened > > > such that it is > > > > permitted that a nil object reference is returned even if > > > the parameter to > > > > _unchecked_narrow is not the nil object reference. > > > > > > > > > What you are trying to say here is that an implementation of > > > _unchecked_narrow > > > should be allowed to fail if it can be sure that the type > > > will not pass > > > the > > > _is_a test, as long as it does not make a remote invocation. > > > > > > The problems with this are : > > > > > > 1) Returning nil is the behaviour > > > that C++ has for failing a narrow test. However, in Java, the > > > BAD_PARAM > > > exception is thrown. This is however, a small problem. > > > > > > 2) The CORBA specification says that an implementation must > > > NOT fail to narrow without calling _is_a() on the remote > object. I > > > think this "directive" applies to the concept ofnarrowing > in general > > > and not just the old narrow. This would clearly be in > > > contravention of > > > your proposal. It can of course succeed in narrowing > without calling > > > _is_a() and _unchecked_narrow() is an extension of this. > > > > > > 3) Since normal narrowing implies a YES answer to > _is_a(), and since > > > _is_a() is > > > (these days) possible to be overridden by the remote object, > > > there is no > > > way proprietary information in an IOR could know what the > application > > > might > > > answer to _is_a(). This is the reason (I believe) for the > directive > > > mentioned > > > in 2) above. > > > > > > We can argue over whether letting applications override > _is_a() was a > > > good > > > idea, but its a fact of life now, so we might as well > live with it. > > > > > > > > > > > The reason is that certain ORB implementations might have > > > the means to do some > > > > limited local validity checking (without depending on a > > > remote system). This > > > > could be done based on ORB proprietary type information in > > > the IOR, e.g. an ORB > > > > might detect from proprietary version info that there is no > > > chance that a > > > > version 3.0 interface is supported by a version 2.0 runtime > > > interface. > > > > > > > > To the applications it could be an advantage if unsupported > > > interfaces are > > > > detected earlier than after invoking an unsupported operation. > > > > > > I agree that it is advantageous if an unsupported interface can > be > > > detected > > > earlier. However, with POA, DSI, and overridden _is_a() one > > > can really > > > never > > > know enough about an object to be able to say > definitively from its > > > object > > > reference only that it does NOT support a particular interface. > > > > > > > > > Any other comments from you folks? > > > > > > Chris > > > > Sender: Chris.Smith@uab.ericsson.se Message-ID: <3846813A.BF4D3D8C@uab.ericsson.se> Date: Thu, 02 Dec 1999 15:24:58 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: messaging issue: unchecked narrow too constrained -> reference? References: Content-Type: multipart/mixed; boundary="------------55C3C2D029312EDF7D5EF430" X-UIDL: =7i!!*7Od9406e9KC4!! hans.kneubuehl@ubs.com wrote: > > Chris, > > it says 'without consulting the object VIA the "is_a" or > "_get_interface" > pseudo-operations' referring to the objref operations. With this > statement it's > not necessarily saying that _is_a objref implementation must do a > remote call > in order to fail to narrow. It is saying someting about how the > narrowing > operation has to be implemented. Of course, the wording is > misleading if during > narrowing, _is_a fails without actually calling the remote object, > but I think > the statement is too weak to infere the directive character that you > are > assigning to it. If this is really the intention, the specs should > at least be > fixed to define this at a more prominent place, e.g. at the > definition of is_a > in 4.3.4.1. I agree that the premises that I base my judgment on are not written in cast iron terms, but nonetheless, I believe this was the intention of these parts of the specifications. > > Additionally, chapter 13 is about ORB interoperability. For > communication > within the same ORB domain, a vendor is allowed to follow different > strategies. Certainly communication within the same ORB domain can be different, but the same semantic apply, and in my opinion, some of the ORB interoperability architecture chapter describes these semantics. For example I believe a CORBA 2.x compliant ORB will have to support the IOR information model (chater 13) even if it is not interoperability compliant (chapter 15). Anyway, if you send me the text of your proposal detailing what statements should be changed and how, I will put it into Vote 2 > > > -----Original Message----- > > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > > Sent: Saturday, November 27, 1999 3:00 PM > > To: Hans z.h.k.k.8. Kneubuehl > > Cc: Chris.Smith; messaging-rtf > > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked narrow > too > > constrained -> reference? > > > > > > hans.kneubuehl@ubs.com wrote: > > > > > > Hi Chris > > > > > > Thanks for the pertinent answer. > > > > > > I can follow all your argumentation, however, I'm not sure > > about the premises > > > it is based on. > > > > > > According to your argumentation, for narrow to fail (return > > nil) on a valid > > > objref (non-nil), it always has to do a remote call, even > > if both the type of > > > the objref and the narrowed-to type were known at compile time. > > > > > > Can you give an exact reference to the "directive" you > > mention in 2), I > > > couldn't find it myself? > > > > In section 13.6.2, in the gospel according to OMG, it says > > > > The typeId, if provided by the server, indicates the most derived > type > > that the server wishes to publish, at the time the reference is > > generated. The objects actual most derived type may later change > to a > > more derived type. Therefore the typeId in the IOR can only be > > interpreted by the client as a hint that the object supports at > least > > the indciated interface. The client can succeed in narrowing the > > reference to the indicated interface, or to one of its base > > interfaces, > > based solely on the type ID in the IOR, but must not fail to > > narrow the > > reference without consulting the object via the "is_a" or > > "_get_interface" pseudo-operations. > > > > By "consult the object" I infer actually communicating with it, > which > > therefore cannot be asynchronous. Hence my inference that > > _unchecked_narrow() cannot fail. > > > > > > > > > > Regards > > > Hans > > > > > > > -----Original Message----- > > > > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > > > > Sent: Saturday, November 27, 1999 1:00 PM > > > > To: Hans z.h.k.k.8. Kneubuehl > > > > Cc: Chris.Smith; messaging-rtf > > > > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked > > narrow too > > > > constrained > > > > > > > > > > > > Hi Hans, > > > > I understand the intention of your message, but there > > > > are several > > > > problems > > > > with doing this. > > > > > > > > > The semanticclient is expecting only asynchronous > communication with the target. Therefore, for the appropriate languages this specification adds an unchecked narrow operation to the IDL mappings for interface. In cases where a safe narrow requires remote communication, this unchecked > narrow always returns a stub of the requested type without checking that the target really implements that interface. Because some implementation might be capable to do the same verifications completely locally, compliant applications must be prepared that this unchecked narrow may return nil for a non-nil object reference. However, note that in case > of interoperability with another ORB, the client must no fail to narrow > the reference without consulting the object via the "is_a" or "_get_interface" pseudo-operations (see CORBA 2.3, 13.6.2). If a > client narrows the target to an unsupported interface type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION." Similarly, for the C++ Language Mapping, change the following text > from orbos/98-05-05 from "Unlike the _narrow function, _unchecked_narrow does not perform any verification that the actual (runtime) type of the parameter object can be widened to the requested Iinterface's type. This function always returns a valid object reference." to "Unlike the _narrow function, _unchecked_narrow does not perform any > remote communication in order to verify that the actual (runtime) type of the > parameter object can be widened to the requested interface's type. In > cases where a safe narrow requires remote communcation, this function always > returns a valid object reference. However, note that compliant applications > must be prepared that _unchecked_narrow may return nil for a non-nil object > reference." Similarly, for the Java Language Mapping, change the following text > from orbos/98-05-05 from "The helper class holds a static unchecked_narrow method that allows a > "org.omg.CORBA.Object" to be narrowed to the object reference of a > more specific type. No type-checking is performed to verify that the object > actually supports the requested type. The IDL exception "CORBA::BAD_OPERATION" > can be expected if unsupported operations are invoked on the new returned > reference, but no failure is indicated at the time of the unchecked_narrow." to "The helper class holds a static unchecked_narrow method that allows a > "org.omg.CORBA.Object" to be narrowed to the object reference of a > more specific type. No type-checking which requires remote communication is > performed to verify that the object actually supports the requested > type. The IDL exception "CORBA::BAD_OPERATION" can be expected if unsupported > operations are invoked on the new returned reference. Compliant applications > still must expect that a failure is indicated by the exception "CORBA::BAD_PARAM" > at the time of the unchecked_narrow." Regards Hans -- Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland phone: +41 1 238 28 96, fax: +41 1 238 30 11 > client is expecting only asynchronous communication with the target. > Therefore, for the appropriate languages this specification adds an > unchecked narrow operation to the IDL mappings for interface. In > cases > where a safe narrow requires remote communication, this > unchecked narrow > always returns a stub of the requested type without checking that > the > target really implements that interface. Because some implementation > might be capable to do the same verifications completely locally, > compliant applications must be prepared that this unchecked narrow > may > return nil for a non-nil object reference. However, note that > in case of > interoperability with another ORB, the client must no fail to > narrow the > reference without consulting the object via the "is_a" or > "_get_interface" pseudo-operations (see CORBA 2.3, 13.6.2). > If a client narrows the > target to an unsupported interface type, invoking the unsupported > operations will raise the system exception CORBA::BAD_OPERATION." > > improvement: Many programming languages map IDL interfaces to programming > constructs that support inheritance. In those language mappings (such as C++ and Java) > that provide a mechanism for narrowing an Object reference of a base > interface to a more derived interface, the act of narrowing may require the full type > hierarchy of the target. In this case, some implementationThis > requirement is not acceptable when a client is expecting only > asynchronous communication with the target. Therefore, for the appropriate > languages this specification adds an unchecked narrow operation to the IDL mappings > for interface. In cases where a safe narrow requires remote communication, > this unchecked narrow always returns a stub of the requested type without > checking that the target really implements that interface. Because some > implementations might be capable to detect a narrowing failure completely locally, > compliant applications must be prepared that unchecked narrow may return nil for > a non-nil object reference. However, note that in case of > interoperability with another ORB, the client must no fail to narrow the reference without > consulting the target via the "is_a" or "_get_interface" pseudo-operations (see > CORBA 2.3, 13.6.2). If a client narrows the target to an unsupported interface > type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION." > Similarly, for the C++ Language Mapping, change the following > text from orbos/98-05-05 from > > "Unlike the _narrow function, _unchecked_narrow does not > perform any verification that the actual (runtime) type of > the parameter object can be widened to the requested > Iinterface's type. This function always returns a valid > object reference." > > to > > "Unlike the _narrow function, _unchecked_narrow does not > perform any remote communication in order to verify that the > actual (runtime) type of the parameter object can be widened > to the requested interface's type. In cases where a safe > narrow requires remote communcation, this function always > returns a valid object reference. However, note that > compliant applications must be prepared that > _unchecked_narrow may return nil for a non-nil object reference." > > > Similarly, for the Java Language Mapping, change the > following text from orbos/98-05-05 from > > "The helper class holds a static unchecked_narrow method that > allows a "org.omg.CORBA.Object" to be narrowed to the object > reference of a more specific type. No type-checking is > performed to verify that the object actually supports the > requested type. The IDL exception "CORBA::BAD_OPERATION" can > be expected if unsupported operations are invoked on the new > returned reference, but no failure is indicated at the time > of the unchecked_narrow." > > to > > "The helper class holds a static unchecked_narrow method that > allows a "org.omg.CORBA.Object" to be narrowed to the object > reference of a more specific type. No type-checking which > requires remote communication is performed to verify that the > object actually supports the requested type. The IDL > exception "CORBA::BAD_OPERATION" can be expected if > unsupported operations are invoked on the new returned > reference. Compliant applications still must expect that a > failure is indicated by the exception "CORBA::BAD_PARAM" at > the time of the unchecked_narrow." > > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > s of narrow > might require either to contact an interface repository or the target itself > to determine whether or not it is safe to narrow the client> client is > expecting only asynchronous communication with the target. > Therefore, for the appropriate languages this specification adds an > unchecked narrow operation to the IDL mappings for interface. In > cases > where a safe narrow requires remote communication, this > unchecked narrow > always returns a stub of the requested type without checking that > the > target really implements that interface. Because some implementation > might be capable to do the same verifications completely locally, > compliant applications must be prepared that this unchecked narrow > may > return nil for a non-nil object reference. However, note that > in case of > interoperability with another ORB, the client must no fail to > narrow the > reference without consulting the object via the "is_a" or > "_get_interface" pseudo-operations (see CORBA 2.3, 13.6.2). > If a client narrows the > target to an unsupported interface type, invoking the unsupported > operations will raise the system exception CORBA::BAD_OPERATION." > > improvement: Many programming languages map IDL interfaces to programming > constructs that support inheritance. In those language mappings (such as C++ and Java) > that provide a mechanism for narrowing an Object reference of a base > interface to a more derived interface, the act of narrowing may require the full type > hierarchy of the target. In this case, some implementationThis > requirement is not acceptable when a client is expecting only > asynchronous communication with the target. Therefore, for the appropriate > languages this specification adds an unchecked narrow operation to the IDL mappings > for interface. In cases where a safe narrow requires remote communication, > this unchecked narrow always returns a stub of the requested type without > checking that the target really implements that interface. Because some > implementations might be capable to detect a narrowing failure completely locally, > compliant applications must be prepared that unchecked narrow may return nil for > a non-nil object reference. However, note that in case of > interoperability with another ORB, the client must no fail to narrow the reference without > consulting the target via the "is_a" or "_get_interface" pseudo-operations (see > CORBA 2.3, 13.6.2). If a client narrows the target to an unsupported interface > type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION." > Similarly, for the C++ Language Mapping, change the following > text from orbos/98-05-05 from > > "Unlike the _narrow function, _unchecked_narrow does not > perform any verification that the actual (runtime) type of > the parameter object can be widened to the requested > Iinterface's type. This function always returns a valid > object reference." > > to > > "Unlike the _narrow function, _unchecked_narrow does not > perform any remote communication in order to verify that the > actual (runtime) type of the parameter object can be widened > to the requested interface's type. In cases where a safe > narrow requires remote communcation, this function always > returns a valid object reference. However, note that > compliant applications must be prepared that > _unchecked_narrow may return nil for a non-nil object reference." > > > Similarly, for the Java Language Mapping, change the > following text from orbos/98-05-05 from > > "The helper class holds a static unchecked_narrow method that > allows a "org.omg.CORBA.Object" to be narrowed to the object > reference of a more specific type. No type-checking is > performed to verify that the object actually supports the > requested type. The IDL exception "CORBA::BAD_OPERATION" can > be expected if unsupported operations are invoked on the new > returned reference, but no failure is indicated at the time > of the unchecked_narrow." > > to > > "The helper class holds a static unchecked_narrow method that > allows a "org.omg.CORBA.Object" to be narrowed to the object > reference of a more specific type. No type-checking which > requires remote communication is performed to verify that the > object actually supports the requested type. The IDL > exception "CORBA::BAD_OPERATION" can be expected if > unsupported operations are invoked on the new returned > reference. Compliant applications still must expect that a > failure is indicated by the exception "CORBA::BAD_PARAM" at > the time of the unchecked_narrow." > > > Regards > Hans > -- > Hans Kneubuehl, UBS AG, P.O. Box, 8098 Zurich, Switzerland > phone: +41 1 238 28 96, fax: +41 1 238 30 11 > s of narrow > might require either to contact an interface repository or the target itself > to determine whether or not it is safe to narrow the clients of unchecked narrow are defined more > > > > constrained than actually > > > > > needed. > > > > > > > > > > The specification states that the _unchecked_narrow > > > > operation always returns a > > > > > valid object reference. I think this should be loosened > > > > such that it is > > > > > permitted that a nil object reference is returned even if > > > > the parameter to > > > > > _unchecked_narrow is not the nil object reference. > > > > > > > > > > > > What you are trying to say here is that an implementation of > > > > _unchecked_narrow > > > > should be allowed to fail if it can be sure that the type > > > > will not pass > > > > the > > > > _is_a test, as long as it does not make a remote invocation. > > > > > > > > The problems with this are : > > > > > > > > 1) Returning nil is the behaviour > > > > that C++ has for failing a narrow test. However, in Java, the > > > > BAD_PARAM > > > > exception is thrown. This is however, a small problem. > > > > > > > > 2) The CORBA specification says that an implementation must > > > > NOT fail to narrow without calling _is_a() on the remote > object. I > > > > think this "directive" applies to the concept ofnarrowing > > in general > > > > and not just the old narrow. This would clearly be in > > > > contravention of > > > > your proposal. It can of course succeed in narrowing > > without calling > > > > _is_a() and _unchecked_narrow() is an extension of this. > > > > > > > > 3) Since normal narrowing implies a YES answer to > > _is_a(), and since > > > > _is_a() is > > > > (these days) possible to be overridden by the remote object, > > > > there is no > > > > way proprietary information in an IOR could know what the > > application > > > > might > > > > answer to _is_a(). This is the reason (I believe) for the > > directive > > > > mentioned > > > > in 2) above. > > > > > > > > We can argue over whether letting applicationclient is > expecting only asynchronous communication with the target. Therefore, for the appropriate languages this specification adds an unchecked narrow operation to the IDL mappings for interface. This unchecked narrow always returns a stub of the requested type without checking that the target really implements that interface. If a client narrows the target to an unsupported interface type, invoking the unsupported operations will raise the system exception CORBA::BAD_OPERATION." to "Many programming languages map IDL interfaces to programming constructs that support inheritance. In those language mappings (such as C++ and Java) that provide a mechanism for narrowing an Object reference of a base interface to a more derived interface, the act of narrowing may require the full type hierarchy of the target. In this case, the implementation of narrow must either contact an interface repository or the target itself to determine whether or not it is safe to narrow the client> client is expecting only asynchronous communication with the target. > Therefore, for the appropriate languages this specification adds an > unchecked narrow operation to the IDL mappings for interface. This > unchecked narrow always returns a stub of the requested type without > checking that the target really implements that interface. If a client > narrows the target to an unsupported interface type, invoking the > unsupported operations will raise the system exception > CORBA::BAD_OPERATION." > > to > > "Many programming languages map IDL interfaces to programming > constructs > that support inheritance. In those language mappings (such as C++ and > Java) that provide a mechanism for narrowing an Object reference of a > base interface to a more derived interface, the act of narrowing may > require the full type hierarchy of the target. In this case, the > implementation of narrow must either contact an interface > repository or > the target itself to determine whether or not it is safe to narrow the > client> client is expecting only asynchronous communication with the target. > Therefore, for the appropriate languages this specification adds an > unchecked narrow operation to the IDL mappings for interface. This > unchecked narrow always returns a stub of the requested type without > checking that the target really implements that interface. If a client > narrows the target to an unsupported interface type, invoking the > unsupported operations will raise the system exception > CORBA::BAD_OPERATION." > > to > > "Many programming languages map IDL interfaces to programming > constructs > that support inheritance. In those language mappings (such as C++ and > Java) that provide a mechanism for narrowing an Object reference of a > base interface to a more derived interface, the act of narrowing may > require the full type hierarchy of the target. In this case, the > implementation of narrow must either contact an interface > repository or > the target itself to determine whether or not it is safe to narrow the > clients override > > _is_a() was a > > > > good > > > > idea, but its a fact of life now, so we might as well > > live with it. > > > > > > > > > > > > > > The reason is that certain ORB implementations might have > > > > the means to do some > > > > > limited local validity checking (without depending on a > > > > remote system). This > > > > > could be done based on ORB proprietary type information in > > > > the IOR, e.g. an ORB > > > > > might detect from proprietary version info that there is no > > > > chance that a > > > > > version 3.0 interface is supported by a version 2.0 runtime > > > > interface. > > > > > > > > > > To the applications it could be an advantage if unsupported > > > > interfaces are > > > > > detected earlier than after invoking an unsupported > operation. > > > > > > > > I agree that it is advantageous if an unsupported interface > can be > > > > detected > > > > earlier. However, with POA, DSI, and overridden _is_a() one > > > > can really > > > > never > > > > know enough about an object to be able to say > > definitively from its > > > > object > > > > reference only that it does NOT support a particular > interface. > > > > > > > > > > > > Any other comments from you folks? > > > > > > > > Chris > > > > > > [] Chris.Smith.vcf Date: Fri, 3 Dec 1999 13:33:14 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Chris Smith cc: hans.kneubuehl@ubs.com, messaging-rtf@omg.org Subject: Re: messaging issue: unchecked narrow too constrained -> > reference? In-Reply-To: <3846813A.BF4D3D8C@uab.ericsson.se> Message-ID: > Organization: Object Oriented Concepts MIME-Version: 1.0 Content-ID: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: a]p!!RJ%e9^`,e9_Ne!! On Thu, 2 Dec 1999, Chris Smith wrote: > > Additionally, chapter 13 is about ORB interoperability. For communication > > within the same ORB domain, a vendor is allowed to follow different strategies. > > Certainly communication within the same ORB domain can be different, but > the same > semantic apply, and in my opinion, some of the ORB interoperability > architecture > chapter describes these semantics. For example I believe a CORBA 2.x > compliant > ORB will have to support the IOR information model (chater 13) even if > it is > not interoperability compliant (chapter 15). No, I don't think so. The information model is relevant only for ORBs that claim interoperability (which is a separate compliance point). For ORBs not making that claim, the internal structure of references can be completely different. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Object Oriented Concepts +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@ooc.com.au AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Dec 1999 09:56:13 +0100 Message-Id: Subject: Re: messaging issue: unchecked narrow too constrained -> portability versus interoperability MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se, michi@ooc.com.au CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Dec 1999 09:56:12 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Dec 1999 09:56:12 +0100" X-UIDL: >77!!?D6!!lLLe9AH9e9 > -----Original Message----- > From: michi [mailto:michi@ooc.com.au] > Sent: Friday, December 03, 1999 4:33 AM > To: Chris.Smith > Cc: michi; Hans z.h.k.k.8. Kneubuehl; messaging-rtf > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked narrow too > constrained -> reference? > > > On Thu, 2 Dec 1999, Chris Smith wrote: > > > > Additionally, chapter 13 is about ORB interoperability. > For communication > > > within the same ORB domain, a vendor is allowed to follow > different strategies. > > > > Certainly communication within the same ORB domain can be > different, but > > the same > > semantic apply, and in my opinion, some of the ORB > interoperability > > architecture > > chapter describes these semantics. For example I believe a CORBA > 2.x > > compliant > > ORB will have to support the IOR information model (chater > 13) even if > > it is > > not interoperability compliant (chapter 15). > > No, I don't think so. The information model is relevant only for > ORBs > that claim interoperability (which is a separate compliance point). > For ORBs not making that claim, the internal structure of references > can be completely different. > ... and thus, portability and interoperability are orthogonal. CORBA compliant code must also run in the case that the client and server don't follow the interoperability interaction model. It cannot rely on features that are only defined for interoperability between different ORBs. Thanks and regards Hans > Cheers, > > Michi. > -- > Michi Henning +61 7 3236 1633 > Object Oriented Concepts +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@ooc.com.au > AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html Sender: Chris.Smith@uab.ericsson.se Message-ID: <38478854.E4295536@uab.ericsson.se> Date: Fri, 03 Dec 1999 10:07:32 +0100 From: Chris Smith Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7C-CCK-MCD [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: sv,en-US MIME-Version: 1.0 To: hans.kneubuehl@ubs.com CC: messaging-rtf@omg.org Subject: Re: messaging issue: unchecked narrow too constrained -> portability versus interoperability References: Content-Type: multipart/mixed; boundary="------------4380DE4D0FF773185E951BB6" X-UIDL: ehod9TSU!!&6-e9_S-!! > ... and thus, portability and interoperability are orthogonal. CORBA compliant > code must also run in the case that the client and server don't follow the > interoperability interaction model. It cannot rely on features that are only > defined for interoperability between different ORBs. > I'm certainly not arguing about this point. I was just referring to some statements in chapter 15 which in my opinion appear to describe what you might call "CORBA semantics" rather than necessarily interoperability. Anyway, send me the text and we'll put it into the next vote. [] Chris.Smith1.vcf From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Dec 1999 17:57:39 +0100 Message-Id: Subject: proposed resolution to issue "'unchecked narrow" MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Dec 1999 17:57:39 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id MAA04597 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Fri, 3 Dec 1999 17:57:39 +0100" X-UIDL: =U5e9dHSd9`P'e9c\Le9 Hi Chris, here's the proposed resolution for the "unchecked narrow" messaging issue for inclusion into vote 2. - Do you know the issue number? - Do you know where section 9.2.5 from the adopted messaging document has gone? They are not part of the new draft which can be found at http://www.omg.org/pub/orbrev/drafts/message_pdf.zip anymore. resolution: ----------- Change the following text at the end of C.1.2 AMI/TII Abstract Model Design in the new draft from "Many programming languages map IDL interfaces to programming constructs that support inheritance. In those language mappings (such as C++ and Java) that provide a mechanism for narrowing an Object reference of a base interface to a more derived interface, the act of narrowing may require the full type hierarchy of the target. In this case, the implementation of narrow must either contact an interface repository or the target itself to determine whether or not it is safe to narrow the client From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Fri, 3 Dec 1999 17:59:57 +0100 Message-Id: Subject: Re: messaging issue: unchecked narrow too constrained -> portability versus interoperability MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Fri, 3 Dec 1999 17:59:57 +0100" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII ;Creation-Date="Fri, 3 Dec 1999 17:59:57 +0100" X-UIDL: R>Ud9D])!!!IH!!HdJe9 > -----Original Message----- > From: Chris.Smith [mailto:Chris.Smith@uab.ericsson.se] > Sent: Friday, December 03, 1999 10:08 AM > To: Hans z.h.k.k.8. Kneubuehl > Cc: Chris.Smith; messaging-rtf > Subject: UNAUTHENTICATED: Re: messaging issue: unchecked narrow too > constrained -> portability versus interoperability > > > > > ... and thus, portability and interoperability are > orthogonal. CORBA compliant > > code must also run in the case that the client and server > don't follow the > > interoperability interaction model. It cannot rely on > features that are only > > defined for interoperability between different ORBs. > > > > I'm certainly not arguing about this point. I was just > referring to some > statements > in chapter 15 which in my opinion appear to describe what you > might call > "CORBA > semantics" rather than necessarily interoperability. > Chris, sorry for this. I didn't want this to address to you but the rtf. In case of interoperability, you are perfectly right that unchecked narrow will never fail, I was wrong. Regards Hans > > Anyway, send me the text and we'll put it into the next vote. > From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Sat, 4 Dec 1999 15:41:17 +0100 Message-Id: Subject: proposed resolution to issue "'unchecked narrow" -> improvement MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 4 Dec 1999 15:41:16 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id JAA27428 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Sat, 4 Dec 1999 15:41:16 +0100" X-UIDL: /([d9Jg8e9Z!Td9W4l!! Chris, inserted below some furhter improvements to the proposed text (in a model differing from the interoperability one, narrow does not necessarily need to consult interface respository or target, e.g. the full type hierarchy of the target could also be coded into the objref) > -----Original Message----- > From: Hans z.h.k.k.8. Kneubuehl > Sent: Friday, December 03, 1999 5:32 PM > To: 'Chris.Smith' > Cc: 'messaging-rtf@omg.org' > Subject: proposed resolution to issue "'unchecked narrow" > > > Hi Chris, > > here's the proposed resolution for the "unchecked narrow" > messaging issue for inclusion into vote 2. > > - Do you know the issue number? > - Do you know where section 9.2.5 from the adopted messaging > document has gone? They are not part of the new draft which > can be found at > http://www.omg.org/pub/orbrev/drafts/message_pdf.zip anymore. > > resolution: > ----------- > Change the following text at the end of > C.1.2 AMI/TII Abstract Model Design in the new draft from > > "Many programming languages map IDL interfaces to programming > constructs > that support inheritance. In those language mappings (such as C++ > and > Java) that provide a mechanism for narrowing an Object reference of > a > base interface to a more derived interface, the act of narrowing may > require the full type hierarchy of the target. In this case, the > implementation of narrow must either contact an interface > repository or > the target itself to determine whether or not it is safe to narrow > the > client From: hans.kneubuehl@ubs.com X-OpenMail-Hops: 2 Date: Sat, 4 Dec 1999 15:41:17 +0100 Message-Id: Subject: proposed resolution to issue "'unchecked narrow" -> improvement MIME-Version: 1.0 TO: Chris.Smith@uab.ericsson.se CC: messaging-rtf@omg.org Content-Disposition: inline; filename="BDY.TXT" ;Creation-Date="Sat, 4 Dec 1999 15:41:16 +0100" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id JAA27428 Content-Type: text/plain; charset=ISO-8859-1 ;Creation-Date="Sat, 4 Dec 1999 15:41:16 +0100" X-UIDL: /([d9Jg8e9Z!Td9W4l!! Chris, inserted below some furhter improvements to the proposed text (in a model differing from the interoperability one, narrow does not necessarily need to consult interface respository or target, e.g. the full type hierarchy of the target could also be coded into the objref) > -----Original Message----- > From: Hans z.h.k.k.8. Kneubuehl > Sent: Friday, December 03, 1999 5:32 PM > To: 'Chris.Smith' > Cc: 'messaging-rtf@omg.org' > Subject: proposed resolution to issue "'unchecked narrow" > > > Hi Chris, > > here's the proposed resolution for the "unchecked narrow" > messaging issue for inclusion into vote 2. > > - Do you know the issue number? > - Do you know where section 9.2.5 from the adopted messaging > document has gone? They are not part of the new draft which > can be found at > http://www.omg.org/pub/orbrev/drafts/message_pdf.zip anymore. > > resolution: > ----------- > Change the following text at the end of > C.1.2 AMI/TII Abstract Model Design in the new draft from > > "Many programming languages map IDL interfaces to programming > constructs > that support inheritance. In those language mappings (such as C++ > and > Java) that provide a mechanism for narrowing an Object reference of > a > base interface to a more derived interface, the act of narrowing may > require the full type hierarchy of the target. In this case, the > implementation of narrow must either contact an interface > repository or > the target itself to determine whether or not it is safe to narrow > the > client