Issue 1997: What does interface substitutability mean in CORBA? (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Thanks to Joaquin Miller, a question came up in the context of the OMA revision work that is going on in ORMSC about what the ORB vendors think "substitutability" means. Resolution: Revised Text: Actions taken: September 29, 1998: received issue October 30, 2000: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jis@fpk.hp.com Date: Tue, 29 Sep 1998 10:20:00 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: orb_revision@omg.org, ab@omg.org Subject: What does interface substitutability mean in CORBA? Thanks to Joaquin Miller, a question came up in the context of the OMA revision work that is going on in ORMSC about what the ORB vendors think 'substitutability' means. The OMA guide currently says: "Interfaces are related to each other by substitutability relationships. Interface A is substitutable for interface B if a client that expects to use an object presenting interface B can get and use a reference to an object with interface A. This must occur without an interaction error. There are many valid substitutability relationships. A common one allows an object to be used anywhere that the client requires an interface comprising a strict subset of the operations in the supplied object's interface, so that the operations that the client could invoke are present with exactly the signatures required. Although the supplied object may also support other operations, this support does not affect the correct operation of the client. Such a relationship is sometimes termed an extension relationship." Does any ORB actually take this broad view of substitutability or do they all depend only on is_a or equivalent/narrowability to determine substitutability? Any thoughts, comments, insights and failing all that, unfounded opinions;-) etc.? Note that I am not looking for a lengthy discussion of the philosophy of substitutability. I am looking for concrete information about what real ORBs do. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Sender: jon@floorboard.com Date: Tue, 29 Sep 1998 12:56:18 -0700 From: Jonathan Biggar To: Jishnu Mukerji CC: orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? References: <3610EC90.FDA9B034@fpk.hp.com> Jishnu Mukerji wrote: > > Thanks to Joaquin Miller, a question came up in the context of the > OMA > revision work that is going on in ORMSC about what the ORB vendors > think > 'substitutability' means. The OMA guide currently says: > > "Interfaces are related to each other by substitutability > relationships. > Interface A is substitutable for interface B if a client that > expects to > use an object presenting interface B can get and use a reference to > an > object with interface A. This must occur without an interaction > error. > There are many valid substitutability relationships. A common one > allows > an object to be used anywhere that the client requires an interface > comprising a strict subset of the operations in the supplied > object's > interface, so that the operations that the client could invoke are > present with exactly the signatures required. Although the supplied > object may also support other operations, this support does not > affect > the correct operation of the client. Such a relationship is > sometimes > termed an extension relationship." > > Does any ORB actually take this broad view of substitutability or do > they all depend only on is_a or equivalent/narrowability to > determine > substitutability? > > Any thoughts, comments, insights and failing all that, unfounded > opinions;-) etc.? Note that I am not looking for a lengthy > discussion of > the philosophy of substitutability. I am looking for concrete > information about what real ORBs do. The definition of substitutability must handle is_a as a special case. Obviously, every response to is_a from Interface A will not be the same as from Interface_B even when A is derived from B: is_a("B") returns true for A & B is_A("A") returns false for B, but true for A so there is a client visible distinction. However, anyone would argue that A must still be considered "substitutable" for B. Since we have seemed to settle, that for IIOP at least, a narrowing call can devolve to a call to is_a, I think that resolving the issue for is_a will handle the problem. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: From: Ed Barkmeyer Date: Tue, 29 Sep 1998 17:58:29 -0400 (EDT) To: jis@fpk.hp.com Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org X-Sun-Charset: US-ASCII The requirement "This must occur without an interaction error." is not enforceable, whatever it is intended to mean. Jon Biggar's comment is on the right track: > The definition of substitutability must handle is_a as a special > case. > Obviously, every response to is_a from Interface A will not be the > same > as from Interface_B even when A is derived from B: > > is_a("B") returns true for A & B > is_A("A") returns false for B, but true for A > > so there is a client visible distinction. However, anyone would > argue > that A must still be considered "substitutable" for B. Jon assumes that the ORB actually supports the "extension relationship" notion by maintaining knowledge of the interface inheritances in the IDL. And in fact, is_a("B") could legitimately return false for an A, even though the A is "substitutable". But you have to realize that this is only the tip of the iceberg. First, certain ORB-detected "interaction errors" can occur that have nothing to do with the substitution per se, but may be a consequence of differences between the expectations of the client and the capabilities of the Object provided. For example, there could be interaction errors that result from negotiation of IIOP character set representation, or from secure-access violations: A's behave like B's, but only X-clients can use A's. Clients can get unexpected results from apparently valid substitutions. Second, "can get and use" makes broad assumptions about the "completeness" of the defined operations. That if on B an operation is defined: long oper(long param); and A inherits oper from B, but (not in IDL) requires that param > 0, then does it make a difference to the client's ability to "use an A" that oper(-1) produces some result on a B but throws an exception on an A? The more complex form of this is the covariance/contravariance question. If B defines long oper(X an_x) and A defines long oper(Y an_Y), what is the required relationship between types X and Y? I believe the current rule is "identity". But since IDL isn't good at specifying limitations on the valid values of a plain type or the valid instances of an interface-type, apparent identity of types doesn't say whether oper(X an_x) is really defined for all valid instances of an_x. And the hidden rules may be different for A's and B's. Related question: What is the relationship of "substitutable" to Objects-by-value? I understood the resolution to be that the passed Object must have all the "state fields" of the required interface, but may have others as well. This is analogous to the "extension relationship" for operations. Is that also to be documented here? -Ed ----------------------------------------------------------------- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division Building 220, Room A127 Tel: +1 301-975-3528 Gaithersburg, MD 20899 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Return-Path: Date: Tue, 29 Sep 1998 20:17:39 -0400 From: "gene.jarboe" Subject: What does interface substitutability mean in CORBA? To: jis@fpk.hp.com Cc: orb_revision@omg.org, ab@omg.org Reply-to: "gene.jarboe" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Jishnu Mukerji and Addressees, Promia Inc.'s and fellow co-worker Troy Caldwell says the following about your question: "What does interface substitutability mean in CORBA?" -----Original Message----- From: Troy Caldwell Date: Tuesday, September 29, 1998 8:05 PM Subject: Re: Fw: What does interface substitutability mean in CORBA? "This is only an issue for the poor souls who wrestle with typed languages (Java, C++,etc). In SmalltalkBroker you can substitute all you want, as long as a selector/signature is available the client could care less about what interface the target really is. Of course this cuts both ways since if the selector isn't available, then you will not find out until runtime, at which time you get a BAD_OPERATION exception." >> -----Original Message----- >> From: Jishnu Mukerji >> To: orb_revision@omg.org ; ab@omg.org >> >> Date: Tuesday, September 29, 1998 3:18 PM >> Subject: What does interface substitutability mean in CORBA? >> >> >Thanks to Joaquin Miller, a question came up in the context of the >> OMA >> >revision work that is going on in ORMSC about what the ORB vendors >> think >> >'substitutability' means. The OMA guide currently says: >> > >> >"Interfaces are related to each other by substitutability >> relationships. >> >Interface A is substitutable for interface B if a client that >> expects to >> >use an object presenting interface B can get and use a reference >> to an >> >object with interface A. This must occur without an interaction >> error. >> >There are many valid substitutability relationships. A common one >> allows >> >an object to be used anywhere that the client requires an >> interface >> >comprising a strict subset of the operations in the supplied >> object's >> >interface, so that the operations that the client could invoke are >> >present with exactly the signatures required. Although the >> supplied >> >object may also support other operations, this support does not >> affect >> >the correct operation of the client. Such a relationship is >> sometimes >> >termed an extension relationship." >> > >> >Does any ORB actually take this broad view of substitutability or >> do >> >they all depend only on is_a or equivalent/narrowability to >> determine >> >substitutability? >> > >> >Any thoughts, comments, insights and failing all that, unfounded >> >opinions;-) etc.? Note that I am not looking for a lengthy >> discussion of >> >the philosophy of substitutability. I am looking for concrete >> >information about what real ORBs do. >> > >> >Thanks, >> > >> >Jishnu. >> >-- >> >Jishnu Mukerji >> >Systems Architect >> >Advanced Development >> >Enterprise Internet Solution Center >> >Enterprise Systems Group >> > >> >Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, >> >Tel: +1 973 443 7528 300 Campus Drive, 2E-62, >> >Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. > > > >-- >* Troy Caldwell >* Promia Inc. (Formerly DNS Technologies Inc.) >* 160 Spear #320 San Francisco CA 94105 USA >* Phone: 415-536-1618 FAX: 415-536-1616 >* Email: troy@promia.com > > Return-Path: Date: Tue, 29 Sep 1998 17:24:39 PDT Sender: Bill Janssen From: Bill Janssen To: orb_revision@omg.org, ab@omg.org, Jishnu Mukerji Subject: Re: What does interface substitutability mean in CORBA? References: <3610EC90.FDA9B034@fpk.hp.com> ILU does not support substitutability in any fashion. That is, ILU requires that "_is_a" returns TRUE for the specified interface before it allows any calls on methods defined in that interface. Bill Return-Path: To: Jishnu Mukerji cc: orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? Date: Wed, 30 Sep 1998 15:40:56 +1000 From: Keith Duddy Hi Jishnu, >Thanks to Joaquin Miller, a question came up in the context of the OMA >revision work that is going on in ORMSC about what the ORB vendors think >'substitutability' means. The OMA guide currently says: > >"Interfaces are related to each other by substitutability relationships. >Interface A is substitutable for interface B if a client that expects to >use an object presenting interface B can get and use a reference to an >object with interface A. This must occur without an interaction error. >There are many valid substitutability relationships. A common one allows >an object to be used anywhere that the client requires an interface >comprising a strict subset of the operations in the supplied object's >interface, so that the operations that the client could invoke are >present with exactly the signatures required. Although the supplied >object may also support other operations, this support does not affect >the correct operation of the client. Such a relationship is sometimes >termed an extension relationship." > >Does any ORB actually take this broad view of substitutability or do >they all depend only on is_a or equivalent/narrowability to determine >substitutability? Don't forget that the only standardised language mapping in the CORBA 1.2 spec was for C - in which case this "broad view" is about all you can really implement. It might be worth extending the OMA's description to say that where refinements of this definition are easliy supported in implementations (such as C++ or Java polymorphism) that a stricter form of substitutability should be allowed. K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Wed, 30 Sep 1998 10:38:42 +0200 To: Jishnu Mukerji From: Guy GENILLOUD Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org, Joaquin Miller At 10:20 AM 9/29/98 -0400, Jishnu Mukerji wrote: >Thanks to Joaquin Miller, a question came up in the context of the OMA >revision work that is going on in ORMSC about what the ORB vendors think >'substitutability' means. The OMA guide currently says: Jishnu, You probably recall that we had a long thread of emails back in April 1996 (I still have a private archive if someone wants it). At one point in the discussion, Andrew Watson issued this message (see "annex" below), and asked all ORB vendors what their implementation does. >From the responses (as far as I understood them) all ORBs relied on signature matching for deciding on interoperability, i.e., substitutability w.r.t. interoperability. In other words, inheritance of interfaces was never required for interoperability. --- When I read the OMG trader spec, I was very surprised to see that the trader requires inheritance for type matching. (The ISO trader spec only considers signature matching). Apparently, the respondents to the Trader RFP were assured that interface inheritance was required for substitutability... *In fact, this was not true*. Several email discussions related to that topic have told me that this issue has never been settled within the OMG. Moreover, ORBs practically (tend to) take the most liberal interpretation. Personnally, as most ODPers, I do not believe that it is possible to maintain a global inheritance graph of interfaces. Cheers Guy ---- annex ----- er: andrew@amethyst.omg.org Date: Mon, 15 Apr 1996 12:06:06 +0100 To: Bill Janssen From: Andrew Watson Subject: Re: [sketch of a new GIOP message format...] Cc: interop@omg.org Bill You wrote: > > ODP allows this. The actual IIOP allows this. The proposal discussed > > here kills this possiblilty, or makes it very impractical. > > But that's OK, because CORBA doesn't allow this. Really? If I build a server with this IDL: interface A { void op1(); void op2();} And a client with this IDL: interface B { void op1();} interface A : B { void op2();} then why would the client using stubs built from the second interface A not be able to invoke operations on server skeletons built from the first? It's the same issue that I raised in my last note: are the two interface A's the same? Answers on a postcard please (saying what your CORBA implementation would do). Cheers, Andrew ----- End Included Message ----- -------------------------------------------------------------------- Dr. Guy Genilloud <http://icawww.epfl.ch/genilloud> Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: Date: Wed, 30 Sep 1998 09:32:57 -0400 From: Paul H Kyzivat Organization: NobleNet To: Guy GENILLOUD CC: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: <199809300837.KAA08396@dimail.epfl.ch> Guy GENILLOUD wrote: ... > When I read the OMG trader spec, I was very surprised to see that > the trader requires inheritance for type matching. > (The ISO trader spec only considers signature matching). > > Apparently, the respondents to the Trader RFP were assured that > interface inheritance was required for substitutability... > *In fact, this was not true*. Several email discussions related to > that topic have told me that this issue has never been settled > within the OMG. Moreover, ORBs practically (tend to) take the most > liberal interpretation. As others have pointed out, substitutability is quite tightly related to the language binding. Our new orb (Nouveau) uses the results of is_a to determine substitutability in the C++ binding. I believe most C++ orbs also do this. (I don't know any other way to implement _narrow correctly in the C++ binding.) > > Personnally, as most ODPers, I do not believe that it is possible > to maintain a global inheritance graph of interfaces. It isn't necessary. Using remote is_a it is only necessary that the server implementing an object be aware of the inheritance graph that its object references conform to. (Knowledge available to the client can be used to optimize away some or all remote is_a calls.) I think the OMA should recognize this as a language binding dependent issue. Return-Path: Date: Wed, 30 Sep 1998 12:01:36 PDT Sender: Bill Janssen From: Bill Janssen To: Guy GENILLOUD , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <199809300837.KAA08396@dimail.epfl.ch> <36123309.2A9390B1@noblenet.com> Actually, ILU internally supports another call beside "_is_a", call "ILUGetTypes", which returns the full type inheritance graph of the most-derived type of the object, using repository IDs to identify the interfaces. We generally use that to get all the interface information in one fell swoop, instead of repeatedly issuing "_is_a" calls. Our implementation figures that the inheritance graph of the interface is just as much a part of the interface as the methods defined in it. That is, we don't allow any interface X to have two different inheritance hierarchies in different `locations'. Bill Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Thu, 01 Oct 1998 11:43:02 +0200 To: Paul H Kyzivat From: Guy GENILLOUD Subject: Re: What does interface substitutability mean in CORBA? Cc: Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <199809300837.KAA08396@dimail.epfl.ch> At 09:32 AM 9/30/98 -0400, Paul H Kyzivat wrote: >Guy GENILLOUD wrote: >... >> When I read the OMG trader spec, I was very surprised to see that >> the trader requires inheritance for type matching. >> (The ISO trader spec only considers signature matching). >> >> Apparently, the respondents to the Trader RFP were assured that >> interface inheritance was required for substitutability... >> *In fact, this was not true*. Several email discussions related to >> that topic have told me that this issue has never been settled >> within the OMG. Moreover, ORBs practically (tend to) take the most >> liberal interpretation. > >As others have pointed out, substitutability is quite tightly related to >the language binding. Our new orb (Nouveau) uses the results of is_a to >determine substitutability in the C++ binding. I believe most C++ orbs >also do this. (I don't know any other way to implement _narrow correctly >in the C++ binding.) The fact that this discussion takes place this issue has never been settled in the OMG. The text quoted by Jishnu confirms that the trader RFP respondents were given false information. But that's not what matters now. In my original message, I used the expression "substitutability w.r.t. interoperability." You are right that there is also the question of "substitutability w.r.t. language bindings", but this was not discussed back in 1996, and different languages bindings seem to have different rules. Clearly, a single definition of substitutability needs to be adopted, and language bindings must support it (no more, no less, certainly no less). Now, I will contend that basing substitutablity should not depend on inheritance. I will give 3 reasons, the second being of particular interest to Telecom. -1- Regarding the use of is_a, I would contend that a call to is_a is useless (or at least: *too late*) when an interface reference was obtained via a formally typed parameter. Either the actual type of the interface conforms to that of the formal parameter, or a type error *already occurred* in the sending ORB, or even earlier than that... On the long term, CORBA should be extended to support early type checking, as suggested in the RM-ODP. Type checking should be performed at well defined points (untyped parameters received), and no type error should possibly occur when receiving reference via a formally typed parameters. To arrive at this kind of support (that many people are looking for, even if they don't understand it well), I fear that inheritance will be a hindrance rather than a help. -2- Another argument against basing substitutablity on inheritance is that other platforms may have different inheritance rules. For example, the GDMO to IDL translation cannot reproduce inheritance in IDL exactly as it is in GDMO. Basing substitutablity on inheritance would hinder substitutablity, even though this is not necessary: substitutablity does NOT depend on GDMO inheritance in the OSI X.7xx specs ("best efforts management"). -3- >> Personnally, as most ODPers, I do not believe that it is possible >> to maintain a global inheritance graph of interfaces. > >It isn't necessary. Using remote is_a it is only necessary that the >server implementing an object be aware of the inheritance graph that >> its >object references conform to. (Knowledge available to the client can >> be >used to optimize away some or all remote is_a calls.) I don't quite understand this, but I must admit that I did not look at CORBA for some time (I never understood how CORBA is supposed to work with multiple IRs...). My concern is about the definition of new *supertypes* (say B) of existing services (type A: A conforms to B). Before introducing such a new supertype, I would need to modify all the IRs of all available servers of the type A. Best regards Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: From: N.P.Sharman@man0506.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Thu, 1 Oct 1998 11:55:48 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Thu, 1 Oct 1998 11:53:35 +0100 Date: Thu, 1 Oct 1998 11:53:35 +0100 X400-Originator: N.P.Sharman@man0506.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000026100001144] X400-Content-Type: P2-1984 (2) Content-Identifier: 1144 Alternate-Recipient: Allowed To: Paul H Kyzivat Cc: orb_revision@omg.org, ab@omg.org References: <36123309.2A9390B1@noblenet.com> Subject: RE(2): What does interface substitutability mean in CORBA? Consider: interface A { void foo(); }; interface B: A { void bar(); }; The mappings for languages like C++ and Java make use of the native type system to ensure that operation foo() can be invoked on A and B references, while operation bar() can be invoked only on B references. However, there's a narrowing operation for B that can try to convert any reference (including a known A reference) to a B reference through which bar() can be invoked. In C, there's effectively only one reference type, CORBA_Object (all others are simply C typedefs), and so foo(), bar() and anything else can be invoked on every reference; it's up to the programmer to decide what, if any, checks to make before doing so. I imagine SmallTalk implementations allow this sort of behaviour, too. Now, what practical checks can the implementors of the narrowing functions, or the C or SmallTalk developer, use to check for substitutability? In my view, there are only two practical tests: * is_a(), which checks the inheritance relationship, and * none. Many C++/Java implementations build is_a() into their narrowing calls; DAIS (http://www.peerlogic.com) makes no check (and so supports the existing notion of substitutability :-). Checking for signature matching would require two or more expensive interrogations of the interface repository, plus some non-trivial code linked into the client. As Paul Kyzivat points out, is_a() can be implemented fairly cheaply, and the POA requires the necessary information (a list of interface identifiers) to be supplied when hooking up a servant. Note that, if we make no check, a faulty assumption about substitutability won't always be rejected with BAD_OPERATION; if by chance the assumeed and actual interfaces both support operation bar(), the call may fail with MARSHAL (e.g. not enough parameter data supplied), BAD_PARAM or even apparent success (e.g. a float was supplied where a long was expected). I'd also suggest that, if a C++ or Java narrowing call makes no check, then the C++/Java developer is given a false sense of confidence; the C++/Java tells them that they have a B reference, when they should make no such assumption. As another contributor points out, even a signature match is no guarantee of _semantic_ substitutability; there may be no intention that the assumed and actual interfaces share a common purpose. On the other hand, given an IDL definition such as: interface B: A { ... }; a reader _ought_ to be able to assume the substitutability of a B for an A, and not just that the definer of B was trying to save keystrokes (use cut'n'paste!). (Of course, B's foo() might still "go wrong", through malice or error, but that's life.) Therefore I suggest that the substitutability test ought to be that of inheritance, for which there is a practical test, and that in strongly typed mappings like C++ and Java, the narrowing operations can legitimately (and eventually should) make that check. Here I disagree with Paul K; I don't think the test should be mapping-dependent: in weakly typed mappings like C and SmallTalk, it's the developer's responsibility to make the check or take the risk, but there is a check available and it's is_a(). Nick Sharman Foxfield Software Limited Return-Path: Date: Thu, 01 Oct 1998 09:23:03 -0400 From: Paul H Kyzivat Organization: NobleNet To: Guy GENILLOUD CC: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: <199809300837.KAA08396@dimail.epfl.ch> <199810010941.LAA22708@dimail.epfl.ch> Guy GENILLOUD wrote: [snip] > Now, I will contend that basing substitutablity should not depend on > inheritance. I will give 3 reasons, the second being of particular > interest to Telecom. > > -1- > > Regarding the use of is_a, I would contend that a call to is_a is > useless (or at least: *too late*) when an interface reference was > obtained via a formally typed parameter. Either the actual type of > the interface conforms to that of the formal parameter, or a type > error *already occurred* in the sending ORB, or even earlier than > that... The issue is somewhat different depending on whether the reference was obtained via a formally typed parameter or not. Suppose it was not - a very common case arising in CosNaming, CosTrader, etc - instead all that is obtained is an Object. Users of this reference need to narrow it to use it. The is_a test is the accepted way to decide if the narrow is legal, if for no better reason than there isn't any other obvious basis on which to make the decision. In this case substitutability is based on inheritance IFF is_a is decided based on inheritance. If you believe substitutability should not be based on inheritance then I think you at least need to propose another way to define is_a. (Note that is_a must be decided without knowledge of the intended use.) The situation is somewhat different if the reference is obtained via a formally typed parameter. In this case the recipient *could* believe what it is told. But this just postpones the problem because it doesn't deal fully with polymorphism. If the actual argument is a an instance of a derived interface, and if the recipient needs to narrow to that interface, we are back to the narrowing problem. > > On the long term, CORBA should be extended to support early type > checking, as suggested in the RM-ODP. Type checking should be > performed at well defined points (untyped parameters received), and > no type error should possibly occur when receiving reference > via a formally typed parameters. To arrive at this kind of support > (that many people are looking for, even if they don't understand > it well), I fear that inheritance will be a hindrance rather than > a help. In languages that have reasonable type systems, people want to be able to use that type system in a natural way. If you come up with a set of type rules that don't map well to the language type system then usage will be to cumbersome to be practical. > > -2- > > Another argument against basing substitutablity on inheritance is > that other platforms may have different inheritance rules. For > example, the GDMO to IDL translation cannot reproduce inheritance > in IDL exactly as it is in GDMO. Basing substitutablity on > inheritance would hinder substitutablity, even though this is not > necessary: substitutablity does NOT depend on GDMO inheritance > in the OSI X.7xx specs ("best efforts management"). Bridging to other platforms based on different models is always going to be a problem. It appears that you have a particular platform that is important to you, and so you would like CORBA to adopt its rules in order to minimize incompatibility between the two. But somebody with another favorite platform will want the rules changed in another way. For instance the changes you suggest would seem to take the CORBA model further away from some of the common language typing models, like C++ and Java. And I can't quite imagine how this would affect bridging to COM. > > -3- > > >> Personnally, as most ODPers, I do not believe that it is possible > >> to maintain a global inheritance graph of interfaces. > > > >It isn't necessary. Using remote is_a it is only necessary that the > >server implementing an object be aware of the inheritance graph > that > its > >object references conform to. (Knowledge available to the client > can > be > >used to optimize away some or all remote is_a calls.) > > I don't quite understand this, but I must admit that I did not look > at CORBA for some time (I never understood how CORBA is supposed to > work with multiple IRs...). > > My concern is about the definition of new *supertypes* (say B) of > existing services (type A: A conforms to B). Before introducing > such > a new supertype, I would need to modify all the IRs of all available > servers of the type A. Revising IDL models in an upward compatible way is an interesting problem - one that as far as I know has not been addressed in a meaningful way. There is a notion of version numbering of repository ids that apparently was intended to be part of a solution to this problem. But just recently the language in the spec was revised to rule out use of the versioning information to decide equivalence between repository ids that differ only in version. This was a pragmatic decision because nobody was prepared to offer a useful weaker definition of equivalence. This is an excellent place for new work. If you are aware of a solution that can be adapted to CORBA then perhaps you should try to get an new RFP initiated on the subject of IDL Evolution. Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Thu, 01 Oct 1998 17:42:24 +0200 To: Paul H Kyzivat From: Guy GENILLOUD Subject: Re: What does interface substitutability mean in CORBA? Cc: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <199809300837.KAA08396@dimail.epfl.ch> <199810010941.LAA22708@dimail.epfl.ch> Paul, In general, I understand your concerns. In fact, I do not really care which direction the OMG goes, as long as the decisions taken are well discussed, and not based on false affirmations or incomplete information. Subtyping is usually not well understood (even by myself). Only a few people really work primarily on this topic (Luca Cardelli, Kim Bruce...) and they all seem to agree that inheritance and subtyping are two different things. Perhaps the reason is that when you "know" what a type is, you no longer need inheritance to decide whether another type is a subtype of that type. I respond more direcltly to your points below. At 09:23 AM 10/1/98 -0400, Paul H Kyzivat wrote: >Guy GENILLOUD wrote: >[snip] >> Now, I will contend that basing substitutablity should not depend on >> inheritance. I will give 3 reasons, the second being of particular >> interest to Telecom. >> >> -1- >> >> Regarding the use of is_a, I would contend that a call to is_a is >> useless (or at least: *too late*) when an interface reference was >> obtained via a formally typed parameter. Either the actual type of >> the interface conforms to that of the formal parameter, or a type >> error *already occurred* in the sending ORB, or even earlier than >> that... > >The issue is somewhat different depending on whether the reference was >obtained via a formally typed parameter or not. Right. There seems to be some confusion here. When I refer to "substitutablity", I mean the capability for a client to work with a server of some type (say B) thinking it is of another type (A). A needs to "conform" to B, in some sense. Everytime a client "narrows" a type, it is operating beyond the nets of type safety (the narrow operation may fail). This is one of the "well-defined points where type checking must be performed" that I was referring to. For performance and type safety reasons, such points should be as few as possible... >Suppose it was not - a >very common case arising in CosNaming, CosTrader, etc - instead all that >is obtained is an Object. Users of this reference need to narrow it to >use it. The is_a test is the accepted way to decide if the narrow is >legal, if for no better reason than there isn't any other obvious basis >on which to make the decision. In this case substitutability is based on >inheritance IFF is_a is decided based on inheritance. > >If you believe substitutability should not be based on inheritance then >I think you at least need to propose another way to define is_a. (Note >that is_a must be decided without knowledge of the intended use.) See the ODP trader spec (with the correction I suggested...). Note that the verification proposed is a *deep* verification of subtyping (applies to parameter types, recursively), while the current definition of is_a is a *shallow* verification. ANSA proposed that type checking be performed by the trader service, rather than by its clients... If you are concerned about "semantic" checks, search for an OMG document #95-12-37. >The situation is somewhat different if the reference is obtained via a >formally typed parameter. In this case the recipient *could* believe >what it is told. But this just postpones the problem because it doesn't >deal fully with polymorphism. If the actual argument is a an instance of >a derived interface, and if the recipient needs to narrow to that >interface, we are back to the narrowing problem. > >> >> On the long term, CORBA should be extended to support early type >> checking, as suggested in the RM-ODP. Type checking should be >> performed at well defined points (untyped parameters received), and >> no type error should possibly occur when receiving reference >> via a formally typed parameters. To arrive at this kind of support >> (that many people are looking for, even if they don't understand >> it well), I fear that inheritance will be a hindrance rather than >> a help. > >In languages that have reasonable type systems, people want to be able >to use that type system in a natural way. If you come up with a set of >type rules that don't map well to the language type system then usage >will be to cumbersome to be practical. I don't think that's a problem, but I could be wrong. A client (usually) knows all the types it is going to work with... >> -2- >> >> Another argument against basing substitutablity on inheritance is >> that other platforms may have different inheritance rules. For >> example, the GDMO to IDL translation cannot reproduce inheritance >> in IDL exactly as it is in GDMO. Basing substitutablity on >> inheritance would hinder substitutablity, even though this is not >> necessary: substitutablity does NOT depend on GDMO inheritance >> in the OSI X.7xx specs ("best efforts management"). > >Bridging to other platforms based on different models is always going >> to >be a problem. It appears that you have a particular platform that is >important to you, and so you would like CORBA to adopt its rules in >order to minimize incompatibility between the two. But somebody with >another favorite platform will want the rules changed in another >> way. We did not hear of any such platform yet... >For instance the changes you suggest would seem to take the CORBA model >further away from some of the common language typing models, like C++ >and Java. The issue is about allowing different inheritance hierarchies in different places, not about suppressing the use of interface inheritance in Java. Note also that C++ does not have a concept of interface separate from that of object or class, and yet, this does not seem to create a problem with CORBA. > And I can't quite imagine how this would affect bridging to COM. Me neither, but COM is famous for its lack of support for any kind of inheritance. Therefore, I suspect that relaxing a constraint on inheritance would help rather than hinder... >> -3- >> >> >> Personnally, as most ODPers, I do not believe that it is >> possible >> >> to maintain a global inheritance graph of interfaces. >> > >> >It isn't necessary. Using remote is_a it is only necessary that >> the >> >server implementing an object be aware of the inheritance graph >> that >> its >> >object references conform to. (Knowledge available to the client >> can >> be >> >used to optimize away some or all remote is_a calls.) >> >> I don't quite understand this, but I must admit that I did not look >> at CORBA for some time (I never understood how CORBA is supposed >> to >> work with multiple IRs...). >> >> My concern is about the definition of new *supertypes* (say B) of >> existing services (type A: A conforms to B). Before introducing >> such >> a new supertype, I would need to modify all the IRs of all >> available >> servers of the type A. > >Revising IDL models in an upward compatible way is an interesting >problem - one that as far as I know has not been addressed in a >meaningful way. There is a notion of version numbering of repository >> ids >that apparently was intended to be part of a solution to this >> problem. >But just recently the language in the spec was revised to rule out >> use >of the versioning information to decide equivalence between >> repository >ids that differ only in version. This was a pragmatic decision >> because >nobody was prepared to offer a useful weaker definition of >> equivalence. > >This is an excellent place for new work. If you are aware of a >> solution >that can be adapted to CORBA then perhaps you should try to get an >> new >RFP initiated on the subject of IDL Evolution. I already quoted most if not all the references I know about. There might be some work in Universities, but not much. I am not in a position where I am motivated to issue an RFP. Again, I do not really care which direction the OMG goes, as long as the decisions taken are well discussed, and not based on false affirmations or incomplete information. At the CORBA level, I can understand that the OMG decides to work with "is_a" as it is defined today (until perhaps a better way is found). However, I would resist placing an obligation to perform is_a calls outside of the control of the programmer (i.e., when they are not needed). Performancewise, making numerous *redundant* calls to "is_a" might not be acceptable. At the OMA level, it might be wise to forsee a change of definition of is_a in the future. Best regards Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: From: Ed Barkmeyer Date: Thu, 1 Oct 1998 12:03:24 -0400 (EDT) To: orb_revision@omg.org Subject: Re: What does interface substitutability mean in CORBA? Cc: ab@omg.org X-Sun-Charset: US-ASCII Paul Kyzivat writes: > If you believe substitutability should not be based on inheritance > then > I think you at least need to propose another way to define > is_a. (Note > that is_a must be decided without knowledge of the intended use.) I fully agree. This was my point (1). At the moment substitutability is NOT required to be based on inheritance, and in fact, not all CORBA implementations do use inheritance, as responses from Bill Janssen and others have pointed out. It was my impression that x->is_a("B") returns true if x is "substitutable for" a B, and otherwise false. Is this wrong? (If it is right, then "is_a" is not portable unless substitutability is well defined.) But if "is_a" is otherwise defined, what is its relationship to the substitutability rule? (And what other presumptions in OMG specifications, in addition to those in Trader, are false?) Putting Paul's point another way, since there are folk who have stated that they don't use inheritance to define substitutability, how do they define "is_a"? Further, do I understand from the discussion that subsitutability is in part a language-dependent behavior? That is, as perceived by the Client, some technically OMA-permissible substitutions will simply not work in his language environment. But I think Paul would characterize these subsitutions as "unreasonable" anyway. Paul says: > In languages that have reasonable type systems, people want to be > able > to use that type system in a natural way. If you come up with a set > of > type rules that don't map well to the language type system then > usage > will be to cumbersome to be practical. But there are two "reasonable" type systems -- strong typing with subtypes and inheritance (Ada, Java), and "typeless" (Lisp, Smalltalk). And there are lots of real languages with "unreasonable" type systems that are somewhere between the two (C, C++, COBOL). And reasonable or not, people want to use the language "in a natural way". I cannot imagine a substitutability rule that will be natural to all of the above. In other words, any rule we choose will be cumbersome to someone. (I believe the current rule was simply designed to be least cumbersome to ORB implementors.) -Ed Return-Path: Date: Thu, 01 Oct 1998 14:01:36 -0400 From: Paul H Kyzivat Organization: NobleNet To: Guy GENILLOUD CC: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: <199809300837.KAA08396@dimail.epfl.ch> <199810010941.LAA22708@dimail.epfl.ch> <199810011540.RAA27331@dimail.epfl.ch> Guy GENILLOUD wrote: A few final replies below, but I am getting tired. > > Paul, > > In general, I understand your concerns. In fact, I do not really > care > which direction the OMG goes, as long as the decisions taken are > well > discussed, and not based on false affirmations or incomplete > information. Inertia rules. The OMG isn't so much going somewhere at this point, it is mostly staying where it is. If you feel it needs to be somewhere else then you will need to overcome the inertia and move it. Annoying though this may seem it is usually a good thing. > >If you believe substitutability should not be based on inheritance > then > >I think you at least need to propose another way to define is_a. > (Note > >that is_a must be decided without knowledge of the intended use.) > > See the ODP trader spec (with the correction I suggested...). > Note that the verification proposed is a *deep* verification of > subtyping (applies to parameter types, recursively), while the > current definition of is_a is a *shallow* verification. I don't understand how to specify this as a replacement for is_a. It requires someone to have access to descriptions of both interfaces. This is not currently the case - is_a passes only a repository id that is (hopefully) known to the server that implements the object. This works for equivalence based on inheritance because the implementor must know all the interfaces the implementation is derived from. But pure structural equivalence means that some type unknown to the implementation may be equivalent to it. At best this could be very inefficient. At worst it could be impossible to implement in real systems. > > ANSA proposed that type checking be performed by the trader > service, rather than by its clients... Well, that is fine if you choose to use a trader. But what about the other 99% of the cases? And I don't know that this translates well to the CosTrader service. I haven't spent a lot of time studying it, but doesn't it set up its own type system independent of CORBA repository ids? That seemed very inconvenient and error prone. > I am not in a position where I am motivated to issue an RFP. Until somebody is it won't happen. > At the CORBA level, I can understand that the OMG decides to work with > "is_a" as it is defined today (until perhaps a better way is found). > However, I would resist placing an obligation to perform is_a calls > outside of the control of the programmer (i.e., when they are not > needed). > Performancewise, making numerous *redundant* calls to "is_a" might > not be acceptable. I don't think there is any such obligation in general. There is perhaps some question whether a reference received via a typed argument needs to be verified to conform to that type. This is more of a robustness issue of the implementation, and is usually optimizable anyway. Return-Path: Sender: jis@fpk.hp.com Date: Thu, 01 Oct 1998 14:06:50 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Ed Barkmeyer Cc: orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? References: <199810011603.MAA19529@titan.cme.nist.gov> Ed Barkmeyer wrote: > > Paul Kyzivat writes: > > If you believe substitutability should not be based on inheritance > then > > I think you at least need to propose another way to define > is_a. (Note > > that is_a must be decided without knowledge of the intended use.) > > I fully agree. This was my point (1). At the moment > substitutability is > NOT required to be based on inheritance, and in fact, not all CORBA > implementations do use inheritance, as responses from Bill Janssen > and > others have pointed out. It was my impression that x->is_a("B") > returns > true if x is "substitutable for" a B, and otherwise false. Is this > wrong? The definition of Object::is_a is as follows: " boolean is_a(in RepositoryId logical_type_id); The logical_type_id is a string denoting a RepositoryId. The operation returns TRUE if the object is really an instance of that type, including if that type is an ancestor of the "most derived" type of that object. This operation exposes to application programmers functionality that must already exist in ORBs which support "types safe narrow" and allows programmers working in environments which do not have compile time type checking to explicitly maintain type safety." Digging in further into the Interface Repository, we find that the InterfaceDef::is_a operation with the signature: boolean is_a(in RepositoryId interface_id); is supposed to "return TRUE if the interface on which it is invoked either is identical to or inherits, directly or indirectly, from the interface identified by its interface_id parameter. Otherwise it returns false." Seems to me like is_a is entirely an inheritance based thing in CORBA. Now whether getting back a TRUE from is_a is the only indicator of substitutability in CORBA is something that I could not find any definitive guidance from the documents. Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: From: Ed Barkmeyer Date: Thu, 1 Oct 1998 16:13:10 -0400 (EDT) To: jis@fpk.hp.com Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org X-Sun-Charset: US-ASCII Thank you, Jishnu for correcting my ignorance. (This is what comes of not really reading the documents, or in some cases, not rereading the documents after v2.0. :-) Jishnu writes: > Seems to me like is_a is entirely an inheritance based thing in > CORBA. I agree that this is the interpretation to be drawn from the quoted text. And this is a change, because IDL "inheritance" used to be a purely lexical concept as far as I can tell. That is, it was exactly the equivalent of #include, and any "subtype" concept was language-dependent until we grew the Repository notions. > Now whether getting back a TRUE from is_a is the only indicator of > substitutability in CORBA is something that I could not find any > definitive guidance from the documents. With Jishnu's clarification, the current substitutability rules allow the ORB to treat Object x as "substitutable" for interface Y even though x->is_a("Y") returns FALSE, i.e. x is-substitutable-for Y does NOT imply x->is_a("Y") == TRUE. But all this really means is that the ORB does not have to ENFORCE the Repository (is_a) model of type-compatibility. In some cases, the language-mapping will provide this enforcement (as Paul said). But in any case, any Client/server practice that violates the Repository type-compatibility model is unsafe. We just don't require the ORB to diagnose it, so maybe it works. It seems to me that the converse IS required: x->is_a("Y") == TRUE implies x is-substitutable-for Y. The Repository that is known to the implementation of object x should reflect the IDL on which the implementation of object x is based. And therefore, if x->is_a("Y") is TRUE, then the implementation of object x must support interface Y, and this implies that x is runtime substitutable for Y even if "structural substitutability" rules are used. Summary: Clients and servers should behave as though the Repository type-compatibility model were binding: x is-substitutable-for Y iff x->is_a("Y") returns TRUE. ORBs are required to ENABLE substitutability whenever x->is_a("Y") returns TRUE, but they may or may not DISABLE substitutability when x->is_a("Y") returns FALSE. Does anyone disagree with this view? (What else did I miss?) Does this answer the intent of Jishnu's original question: What is the real substitutability rule in use? The answer is: "That's an ORB implementation concern. The OMA rule should be the above." -Ed P.S. I note that no one has yet raised the issue of "substitutability meets versioning". Return-Path: Date: Thu, 1 Oct 1998 13:54:03 PDT Sender: Bill Janssen From: Bill Janssen To: Guy GENILLOUD , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <199809300837.KAA08396@dimail.epfl.ch> <199810010941.LAA22708@dimail.epfl.ch> <199810011540.RAA27331@dimail.epfl.ch> <3613C380.C767C7FD@noblenet.com> Excerpts from local.omg: 1-Oct-98 Re: What does interface sub.. Paul H Kyzivat@noblenet. (3707*) > But > pure structural equivalence means that some type unknown to the > implementation may be equivalent to it. And this, I believe, is the core of the discussion. My position is that interface structural definitions, as available with OMG IDL, are insufficient for the purposes of comparing two interfaces to see if they are `the same'. Additional information about the interface not directly expressible in OMG IDL (for good and sufficient reasons, by the way) is captured in the repository ID of the interface. One interface is therefore `substitutable' for another only if it (1) has the same repository ID, or (2) includes or encompasses the other interface via inheritance. Specifically, one interface is not substitubable for another simply because its methods have the same signatures. Bill Return-Path: Date: Thu, 01 Oct 1998 17:03:03 -0400 From: "gene.jarboe" Subject: Re: What does interface substitutability mean in CORBA? To: Ed Barkmeyer , jis@fpk.hp.com Cc: orb_revision@omg.org, ab@omg.org Reply-to: "gene.jarboe" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Ed Barkmeyer and Addressees, You said "...But all this really means is that the ORB does not have to ENFORCE the Repository (is_a) model of type-compatibility. In some cases, the language-mapping will provide this enforcement (as Paul said). But in any case, any Client/server practice that violates the Repository type-compatibility model is unsafe. We just don't require the ORB to diagnose it, so maybe it works..." Hummm...if any of what you say above is TRUE, then it will be interesting to see how ORB vendors will make assurance statements about their security ORBs in a truly heterogeneous distributed ORB environment. Right? :-) Regards, Gene Jarboe :-) Senior Security Scientist Promia, Inc. formerly DNS Technologies, Inc. (Home of Visual Enterprise Information Server & SmalltalkBroker/SecureBroker) Home Phone: (410) 647-4671 Work Phone : (410) 421-5146 Fax Phone : (410) 421-5146 -----Original Message----- From: Ed Barkmeyer To: jis@fpk.hp.com Cc: orb_revision@omg.org ; ab@omg.org Date: Thursday, October 01, 1998 4:47 PM Subject: Re: What does interface substitutability mean in CORBA? >Thank you, Jishnu for correcting my ignorance. (This is what comes of >not really reading the documents, or in some cases, not rereading the >documents after v2.0. :-) > >Jishnu writes: >> Seems to me like is_a is entirely an inheritance based thing in CORBA. > >I agree that this is the interpretation to be drawn from the quoted >text. And this is a change, because IDL "inheritance" used to be >a purely lexical concept as far as I can tell. That is, it was exactly >the equivalent of #include, and any "subtype" concept was >language-dependent until we grew the Repository notions. > >> Now whether getting back a TRUE from is_a is the only indicator of >> substitutability in CORBA is something that I could not find any >> definitive guidance from the documents. > >With Jishnu's clarification, the current substitutability rules >allow the ORB to treat Object x as "substitutable" for >interface Y even though x->is_a("Y") returns FALSE, i.e. > x is-substitutable-for Y does NOT imply x->is_a("Y") == TRUE. >But all this really means is that the ORB does not have to ENFORCE >the Repository (is_a) model of type-compatibility. In some cases, >the language-mapping will provide this enforcement (as Paul said). >But in any case, any Client/server practice that violates the >Repository type-compatibility model is unsafe. We just don't >require the ORB to diagnose it, so maybe it works. > >It seems to me that the converse IS required: > x->is_a("Y") == TRUE implies x is-substitutable-for Y. >The Repository that is known to the implementation of object x should >reflect the IDL on which the implementation of object x is based. >And therefore, if x->is_a("Y") is TRUE, then the implementation of >object x must support interface Y, and this implies that x is >runtime substitutable for Y even if "structural substitutability" >rules are used. > >Summary: Clients and servers should behave as though the Repository >type-compatibility model were binding: > x is-substitutable-for Y iff x->is_a("Y") returns TRUE. >ORBs are required to ENABLE substitutability whenever x->is_a("Y") >returns TRUE, but they may or may not DISABLE substitutability when >x->is_a("Y") returns FALSE. > >Does anyone disagree with this view? (What else did I miss?) > >Does this answer the intent of Jishnu's original question: What is >the real substitutability rule in use? The answer is: "That's an >ORB implementation concern. The OMA rule should be the above." > >-Ed > >P.S. I note that no one has yet raised the issue of "substitutability >meets versioning". > > > Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Thu, 01 Oct 1998 17:09:11 -0400 To: Jishnu Mukerji From: Steve Vinoski Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org References: <199810011603.MAA19529@titan.cme.nist.gov> At 02:06 PM 10/1/98 -0400, Jishnu Mukerji wrote: >Now whether getting back a TRUE from is_a is the only indicator of >substitutability in CORBA is something that I could not find any >definitive guidance from the documents. Another form of substitutability that I believe CORBA supports is based only on operation signatures. Specifically, with the DII one can create a request based only on operation name and not based at all on interface type. As long as the requesting DII application can provide the right number and types of arguments, it can invoke the operation regardless of what interface(s) the target object supports. This means that if two objects support an operation with the same name and signature, you could substitute one for the other without having to change your DII client code whatsoever. Again, it comes back to semantics, as someone else (Ed?) already pointed out. --steve Return-Path: Sender: jis@fpk.hp.com Date: Thu, 01 Oct 1998 17:46:18 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Laboratories To: Steve Vinoski Cc: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? References: <199810011603.MAA19529@titan.cme.nist.gov> <199810012109.RAA20631@boston.iona.ie> Steve Vinoski wrote: > > At 02:06 PM 10/1/98 -0400, Jishnu Mukerji wrote: > >Now whether getting back a TRUE from is_a is the only indicator of > >substitutability in CORBA is something that I could not find any > >definitive guidance from the documents. > > Another form of substitutability that I believe CORBA supports is > based > only on operation signatures. Specifically, with the DII one can > create a > request based only on operation name and not based at all on > interface > type. As long as the requesting DII application can provide the > right > number and types of arguments, it can invoke the operation > regardless of > what interface(s) the target object supports. This means that if two > objects support an operation with the same name and signature, you > could > substitute one for the other without having to change your DII > client code > whatsoever. Again, it comes back to semantics, as someone else (Ed?) > already pointed out. That's true. However, that is substitution at the operation level - sort of an RPC thing and not particularly an "Object" thing in some sense. Is there a corresponding interface level substitutability based on structural considerations available in CORBA? One could define one using an extension of the "equivalent" operation (e.g. for structs) as defined in the IFR I suppose, but for now equivalence of interfaces is based purely on REPID and TypeCode. To put a radical spin on this, it seems to me that all substitutability is incidental in CORBA. Substitutability is not a first class concept in the sense TypeCode equivalence or inheritance is. It is incidental that objects that are related via is_a happen to have characteristics that make them substitutable in some sense - the sense that they land up with interfaces of the same shape. My contention is, if substitutability (and there can be many kinds - syntactic, semantic etc.) were a first class concept then we would have a "is_substitutable" operation, perhaps on object reference, with precisely defined semantics, that one could use to definitively determine substitutability, according to those semantics. (In some sense, is_a does precisely that relative to inheritance semantics) Absent that everyone does whatever suits their taste in their implementation. The IFR and the Object interface forces them to at least do the is_a thing consistently. Jishnu. -- Jishnu Mukerji Systems Architect Advanced Development Enterprise Internet Solution Center Enterprise Systems Group Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Thu, 01 Oct 1998 18:05:24 -0400 From: "gene.jarboe" Subject: Re: What does interface substitutability mean in CORBA? To: Jishnu Mukerji Cc: Ed Barkmeyer , jis@fpk.hp.com, orb_revision@omg.org, ab@omg.org Reply-to: "gene.jarboe" X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Jishnu, Please see my comments inserted into your message below. Gene -----Original Message----- From: Jishnu Mukerji To: gene.jarboe Cc: Ed Barkmeyer ; jis@fpk.hp.com ; orb_revision@omg.org ; ab@omg.org Date: Thursday, October 01, 1998 5:30 PM Subject: Re: What does interface substitutability mean in CORBA? >gene.jarboe wrote: >> >> Ed Barkmeyer and Addressees, >> >> You said "...But all this really means is that the ORB does not have >> to ENFORCE >> the Repository (is_a) model of type-compatibility. In some cases, >> the language-mapping will provide this enforcement (as Paul said). >> But in any case, any Client/server practice that violates the >> Repository type-compatibility model is unsafe. We just don't >> require the ORB to diagnose it, so maybe it works..." >> >> Hummm...if any of what you say above is TRUE, then it will be >> interesting to see how >> ORB vendors will make assurance statements about their security ORBs in a >> truly >> heterogeneous distributed ORB environment. Right? :-) > >Could you elaborate? If an ORB is enforcing some type of interdomain security policy and the Respository type-compatibility model is "unsafe," what does this mean to integrity, assurance, secure interoperability and etc.? Or will the CORBA ORBs ( or the OMA?) depend on the platform's operating system to make statements about its security and reliability? >Just because one interface is substitutable for >another does not mean that the Security attributes of said interface >instance are substituted for that of the others. Substitutability interface could be a problem for certain security domains wherein the security policy dictates "that one interface cannot be substituted with another." Correct? (see my above questions) >What is the >relationship of this to assurance? Now that is of course not to say that >creating assurance statements for a heterogeneous distributed >environments in general is an easy problem to solve.:-) Assurance is always a serious and hard problem, but the CORBA and the OMA standards must take it into consideration, in my belief. Some organizations and OO environments are going to need some predictions on OO behavior when certain senstive objects are invoked. Agreed? Further, if the consumer isn't made aware of these assurance issues then how will they know? > >Jishnu. >-- >Jishnu Mukerji >Systems Architect >Advanced Development >Enterprise Internet Solution Center >Enterprise Systems Group > >Email: jis@fpk.hp.com Hewlett-Packard New Jersey Labs, >Tel: +1 973 443 7528 300 Campus Drive, 2E-62, >Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Return-Path: Date: Thu, 01 Oct 1998 18:39:59 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bill Janssen CC: Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: <199809300837.KAA08396@dimail.epfl.ch> <199810010941.LAA22708@dimail.epfl.ch> <199810011540.RAA27331@dimail.epfl.ch> <3613C380.C767C7FD@noblenet.com> Bill Janssen wrote: > > Excerpts from local.omg: 1-Oct-98 Re: What does interface sub.. Paul > H > Kyzivat@noblenet. (3707*) > > > But > > pure structural equivalence means that some type unknown to the > > implementation may be equivalent to it. > > And this, I believe, is the core of the discussion. My position is > that > interface structural definitions, as available with OMG IDL, are > insufficient for the purposes of comparing two interfaces to see if > they > are `the same'. Additional information about the interface not > directly > expressible in OMG IDL (for good and sufficient reasons, by the way) > is > captured in the repository ID of the interface. One interface is > therefore `substitutable' for another only if it (1) has the same > repository ID, or (2) includes or encompasses the other interface > via > inheritance. > > Specifically, one interface is not substitubable for another simply > because its methods have the same signatures. I strongly agree! Guy seems to be interested in evolution of interfaces and introduction of new ancestors. There are some modifications that seem like they would be valid, but coming up with a new notion of substitutability or is_a that covers them seems daunting. For instance consider the following: module M1 { interface A { void f(); void g();}; }; module M2 { interface D : A { void h(); }; }; Now server S implements D, and publishes a reference to an instance of D in a nameserver (cast as type Object). Client C knows about M1 but not M2. It obtains the reference that S published, and wants to use it as type A, so it narrows it. The client's orb, not having heard of D's repository id, calls is_a(A's repid) on the object. The server S knows that repid and so can answer TRUE. Everybody is happy. But now, lets make a change. Redefine M1 as follows and rebuild the client C and its interface repository, while leaving the server S unchanged (based on the old definition of M1): module M1' { interface X { void f();}; interface A' : X { void g();}; }; This really doesn't affect the definition of A in any major way. Probably if the client is otherwise unchanged everything would continue to work as described above. But now lets change the client C so that it tries to narrow the object to an X rather than an A. It calls is_a(X's repid) on the object. The server S doesn't know that repid and so it answers FALSE. The client is not happy. - Does C have any right to expect the object to be narrowable to an A? To an X? - when the change was made to M1, what repository ids should have been given new version numbers? Certainly M1, but what about A? This kind (and others) of interface evolution is almost certainly required for substantial CORBA based applications to live and prosper. But it seems out of scope for CORBA as it exists today. Return-Path: X-Sender: andrew@emerald.omg.org Date: Thu, 1 Oct 1998 21:44:33 -0400 To: Jishnu Mukerji From: Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org Jishnu, A very long time ago (about last Tuesday)* you wrote: > Thanks to Joaquin Miller, a question came up in the context of the OMA > revision work that is going on in ORMSC about what the ORB vendors think > 'substitutability' means. The OMA guide currently says: > > "Interfaces are related to each other by substitutability relationships. > Interface A is substitutable for interface B if a client that expects to > use an object presenting interface B can get and use a reference to an > object with interface A. This must occur without an interaction error. > There are many valid substitutability relationships. A common one allows > an object to be used anywhere that the client requires an interface > comprising a strict subset of the operations in the supplied object's > interface, so that the operations that the client could invoke are > present with exactly the signatures required. Although the supplied > object may also support other operations, this support does not affect > the correct operation of the client. Such a relationship is sometimes > termed an extension relationship." > > Does any ORB actually take this broad view of substitutability or do > they all depend only on is_a or equivalent/narrowability to determine > substitutability? Well, I seem to have missed my cue to enter this well-rehearsed discussion, but I'm happy to see all the usual players are on stage, and everyone else seems to remember their lines perfectly from previous performances. :-) At the risk of causing utter consternation in the audience, I'd like to propose we clearly separate the discussion into two threads: A. A theological, er sorry *theoretical*, debate on how things should be in an ideal world. I'll happily pitch in with my usual opinions, which roughly speaking means siding with Ed, Guy and Steve against the Forces of Darkness (Hello Bill :-). (Incidentally, there are no prizes for guessing who originally wrote the text Joaquin quoted from the OMA). B. Answering the question Jishnu posed, namely "what should go into the OMA to reflect the reality of shipping products"? Regretfully leaving aside for now the chance to do battle in discussion (A), I'd like to help bring some resolution to (B). I suggest we insert text in CORBA and/or the OMA to say something like this: "When a client is performing operation invocation via stubs built from an IDL interface description, ORB implementations shall support interaction when the IDL used to build the server skeleton is the same as, or inherits from, that used to build the client stub. When a client uses the DII to invoke an operation on a server, ORB implementations shall support interaction if the server provides an operation whose name matches that given by the client, and all corresponding supplied and formal parameters agree exactly in type. In all other cases behaviour is not defined by this specification (i.e. the interaction may be flagged as an error, or supported as a vendor extension, or silently fail without flagging an error)." Something like this seems to me to reflect what the range of real products does. It allows C and Smalltalk ORBs implementing the broad definition of substitutability to be compliant without making C++ ORBs that use an is_a substitutability test be non-compliant. The language could certainly do with cleaning up - especially the DII paragraph, which fails to say how the server operations are defined (IDL? DSI?) and what "matches" means. But it's a start. Comments? Cheers, Andrew * There's a small prize for correctly identifying the origin for this slightly mis-quoted phrase. Sorry, but I couldn't resist :-). Return-Path: To: Guy GENILLOUD cc: Paul H Kyzivat , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? Date: Fri, 02 Oct 1998 12:07:34 +1000 From: Keith Duddy >At 09:32 AM 9/30/98 -0400, Paul H Kyzivat wrote: >>Guy GENILLOUD wrote: >>... >>> When I read the OMG trader spec, I was very surprised to see that >>> the trader requires inheritance for type matching. >>> (The ISO trader spec only considers signature matching). >>> >>> Apparently, the respondents to the Trader RFP were assured that >>> interface inheritance was required for substitutability... >>> *In fact, this was not true*. Several email discussions related to >>> that topic have told me that this issue has never been settled >>> within the OMG. Moreover, ORBs practically (tend to) take the most >>> liberal interpretation. >> >>As others have pointed out, substitutability is quite tightly related to >>the language binding. Our new orb (Nouveau) uses the results of is_a to >>determine substitutability in the C++ binding. I believe most C++ orbs >>also do this. (I don't know any other way to implement _narrow correctly >>in the C++ binding.) > >The fact that this discussion takes place this issue has never >been settled in the OMG. The text quoted by Jishnu confirms that >the trader RFP respondents were given false information. >But that's not what matters now. In fact the trader submitters were all aware that in all ORB implementations that all of had collectively used (barring Object Broker C language binding) that inheritance was the only mechanism used to determine subtitutability. Many of us had been involved in defining substituability in the ODP standard (which is the basis for the OMA definition). The decision to use inhertiance as the basis for Trading was made because of the semantics of the interface type - not simply in order to "avoid interaction errors" as the OMA states. Remember that Trading is determining non-functional properties of services - not getting the exection of an operation correct at a protocol and marshalling level. One final point - the ISO Trader specification is the same as the OMG trader specification, and therefore uses the same service subtyping concepts. K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Fri, 02 Oct 1998 11:01:45 +0200 To: Andrew Watson From: Guy GENILLOUD Subject: Re: What does interface substitutability mean in CORBA? Cc: Jishnu Mukerji , orb_revision@omg.org, ab@omg.org References: <3610EC90.FDA9B034@fpk.hp.com> At 09:44 PM 10/1/98 -0400, Andrew Watson wrote: >At the risk of causing utter consternation in the audience, I'd like to >propose we clearly separate the discussion into two threads: > >A. A theological, er sorry *theoretical*, debate on how things should be in > an ideal world. I'll happily pitch in with my usual opinions, which > roughly speaking means siding with Ed, Guy and Steve against the Forces > of Darkness (Hello Bill :-). (Incidentally, there are no prizes for > guessing who originally wrote the text Joaquin quoted from the OMA). > >B. Answering the question Jishnu posed, namely "what should go into the OMA > to reflect the reality of shipping products"? > >Regretfully leaving aside for now the chance to do battle in discussion >(A), I'd like to help bring some resolution to (B). Hi Andrew, I am very happy about your suggestion. In fact, I was just about to suggest something along thoses lines (minus your very concrete and useful resolution text). >From a theoretical perspective, I come to realize that, since all IDL interfaces inherit from is_a, then *strictly speaking*, substitutability is not possible in CORBA. Or say, substitutability is only possible w.r.t. some conditions, such as not using is_a with some values... This explains a lot of the confusion that we see in the present discussion. So, I agree that OMA should say something along the lines you suggested. What I am against is to introduce, in the OMA, a "pseudo-theory" of subtyping and substitutability based on inheritance. Ed Barkmeyer confirmed to me that all theoretical work points in the other direction. Finally, I'll quote Paul H Kyzivat: << This kind (and others) of interface evolution is almost certainly required for substantial CORBA based applications to live and prosper. But it seems out of scope for CORBA as it exists today.>> (see Paul's last message). I fully agree with Paul here. I'll add that the OMA should take that concern into account. Best regards Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: cc: Guy GENILLOUD , Paul H Kyzivat , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? Date: Fri, 02 Oct 1998 13:55:06 +1000 From: Keith Duddy Oops - I should be wary of making assertions regarding processes where I wasn't present in the room at the time.... >In fact the trader submitters were all aware that in all ORB >implementations that all of had collectively used (barring Object >Broker C language binding) that inheritance was the only mechanism >used to determine subtitutability. Many of us had been involved in >defining substituability in the ODP standard (which is the basis for >the OMA definition). The decision to use inhertiance as the basis for >Trading was made because of the semantics of the interface type - not >simply in order to "avoid interaction errors" as the OMA states. >Remember that Trading is determining non-functional properties of >services - not getting the exection of an operation correct at a >protocol and marshalling level. I was present here, and believe that our decision was based on semantics of services behind the interfaces... >One final point - the ISO Trader specification is the same as the OMG >trader specification, and therefore uses the same service subtyping >concepts. But not here - and although I know the standard was jointly adopted I seem ts unaware of the ODP specific differences - I appear to have got this wrong.... K -- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Keith Duddy : dud at dstc.edu.au : http://www.dstc.edu.au/AU/staff/dud CRC for Distributed Systems Technology (DSTC) General Purpose South, University of Queensland, 4072, Australia ph: +61 7 336 5 4310 :: fx: +61 7 336 5 4311 ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2nd edition of my book ``Java Programming with CORBA'' now in bookshops >>> http://www.wiley.com/compbooks/vogel <<< ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Return-Path: From: Ed Barkmeyer Date: Fri, 2 Oct 1998 10:31:54 -0400 (EDT) To: gene.jarboe@mci2000.com Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org X-Sun-Charset: US-ASCII Gene, You wrote: > If an ORB is enforcing some type of interdomain security policy and > the > Respository type-compatibility model is "unsafe," what does this > mean to > integrity, assurance, secure interoperability and etc.? I emphatically did NOT say that the repository type-compatibility model is unsafe. I said that any client/server practice that VIOLATES it is unsafe. The only question is whether the ORB diagnoses all runtime violations. I have NO idea what the relationship of the security model to inheritance is. I am willing to believe that an ORB that enforces secure interoperability might have to enforce the A is-substitutable-for B iff A is_a B rule, but it would sure help to have an example. That is, can you describe a scenario in which a) the ORB uses a "weaker" substitutability rule (e.g. "structural substitutability" -- A supports all the B signatures, regardless of how A was declared), and b) a malevolent client uses this weakness to create a security breach ? You also wrote: > Substitutability interface could be a problem for certain security > domains wherein the security policy dictates "that one interface > cannot be substituted with another." This is a horse of an entirely different color. If the policy dictates a "special substitutability rule" for a particular interface -- namely that the passed object must have been DECLARED to be of exactly the expected type -- then that rule must be used for that interface, and the usual substitutability rules used by the ORB, whatever they may be, will not apply. (Is this really something secure ORBs must be able to do?) I observed previously that unexpected substitutions can cause the client to experience unexpected security exceptions, but that situation is not a "secure interoperability" problem. The security is maintained, but the client experiences an unexpected failure. (We can talk about the wider security problem of causing a critical system to FAIL by using a systemic weakness to poison a component, but that has nothing to do with "secure interoperability". That doesn't compromise information; it compromises availability.) -Ed Return-Path: From: Ed Barkmeyer Date: Fri, 2 Oct 1998 12:41:43 -0400 (EDT) To: andrew@omg.org Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org X-Sun-Charset: US-ASCII Andrew writes: > I suggest we insert text in CORBA and/or the OMA to say something > like this: > > "When a client is performing operation invocation via stubs built > from an > IDL interface description, ORB implementations shall support > interaction > when the IDL used to build the server skeleton is the same as, or > inherits from, that used to build the client stub. Is this intended to be an "abstract specification"? I agree that this is the desired behavioral rule. I just want to be sure that this is intentional OMA-speak and that everyone understands the *current* implication to be that "the IDL used to build" refers to Repository objects and that exactly the Repository "is_a" test, which may involve a runtime comparison between descriptions maintained in two Repositories (Guy's comment), must succeed. Being careful, this does not mean that the ORB implementation has to DO the Repository check. It means that the operation invocation is only valid if the Repository check WOULD SUCCEED (if actually performed). Note that this is not only a requirement on the Client. There is a matching requirement that Servers may only return objects that would satisfy the Repository check for the nominal return value type. (And the ORB does not actually have to check this either.) > When a client uses the DII to invoke an operation on a server, ORB > implementations shall support interaction if the server provides > an operation whose name matches that given by the client, and all > corresponding supplied and formal parameters agree exactly in type. Agree in principle. I would be more comfortable with: When a client uses the DII to invoke an operation on an object, ORB implementations shall support interaction if the object supports ... > In all other cases behaviour is not defined by this specification (i.e. > the interaction may be flagged as an error, or supported as a vendor > extension, or silently fail without flagging an error)." Exactly. What is stated is the model of VALID Client/Server interaction. The ORB is required to support all valid interactions, and no requirement is made for the ORB behaviour when the interaction is invalid. It seems that we agree on the practical as well as the theological. -Ed > * There's a small prize for correctly identifying the origin for this > slightly mis-quoted phrase. Sorry, but I couldn't resist :-). "A long, long time ago, about last Friday" is from A.A. Milne's "Winnie-the-Pooh". Sorry, I couldn't resist the challenge! :-) Return-Path: From: "MILLER, Joaquin" To: "'Guy GENILLOUD'" , "'Andrew Watson'" , "'Jishnu Mukerji'" Cc: "'orb_revision@omg.org'" , "'ab@omg.org'" Subject: RE: What does interface substitutability mean in CORBA? Date: Fri, 2 Oct 1998 08:27:22 -0700 I've stayed out of this so far, but this seems like a good point to say two things. Joaquin Miller >-----Original Message----- >From: Guy GENILLOUD [SMTP:guy.genilloud@dimail.epfl.ch] >Sent: Friday, October 02, 1998 4:02 AM > ... Or say, substitutability is only possible w.r.t. some conditions, such >as not using is_a with some values... This explains a lot of the confusion >that we see in the present discussion. >[Miller] Good old ODP: "An object is behaviourally compatible with a second >object with respect to a set of criteria (see notes) if the first object can >replace the second object without the environment being able to notice the >difference in the objects' behaviour on the basis of the set of criteria." >["set of criteria" = "some conditions"] > >http://www.iso.ch:8000/RM-ODP/Part2/9.html#9.4 > > >So, I agree that OMA should say something along the lines you suggested. What >I am against is to introduce, in the OMA, a "pseudo-theory" of subtyping and >substitutability based on inheritance. >[Miller] Is it not the case that the OMG a l r e a d y has a theory of >substitutability based on inheritance? See the section 4.4.6 of the OMA >Guide. > >http://enterprise.Systemhouse.MCI.com/omwg/guide.html > >Of course, the purpose of the discussion is to come up with the c u r r e n >t theory. > > >[Miller] I am not taking any position. I am here to learn. Just calling >attention to relevant texts. > >I do have a goal, though. The venerable OMA Guide says in 4.4.5: "The Core >Object Model does not directly address these issues, but simply uses the term >type to cover the union of the interface plus all the other properties of an >object that determine whether it is suitable for a particular purpose." > >I'd like to see a definition of substitutability in the Core model that is >about "suitable for a particular purpose." > >The CORBA model can then tell us what the CORBA criteria for substitutability >do to help determine substitutability in the Core sense. > >I find the distinction between "interaction error" and "application error" in >OMA Guide to be right on. [Would the English be 'smack on'?] > > Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Sat, 3 Oct 1998 08:36:18 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Bill Janssen , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? Content-ID: On Thu, 1 Oct 1998, Paul H Kyzivat wrote: I'm back from holidays, so I'm free to disagree with Paul again :-) > But now, lets make a change. Redefine M1 as follows and rebuild the > client C and its interface repository, while leaving the server S > unchanged (based on the old definition of M1): > > module M1' { > interface X { void f();}; > interface A' : X { void g();}; > }; > > This really doesn't affect the definition of A in any major way. > Probably if the client is otherwise unchanged everything would > continue > to work as described above. > > But now lets change the client C so that it tries to narrow the > object > to an X rather than an A. It calls is_a(X's repid) on the > object. The > server S doesn't know that repid and so it answers FALSE. The client > is > not happy. I agree with the analysis. However, I think this scenario is simply not legal. Once an IDL type has been defined, it becomes immutable and cannot be changed. The scenario above really contains two "no-nos" as far as I can see: - It changes an existing IDL type. - It uses different IDL definitions with identical repository IDs for client and server. CORBA cannot cope with either of these. If an existing IDL type is changed in any way at all, clients may get surprises, as Paul points out. There are lots of ways to surprise the client, depending on exactly what change is made. If client and server do not agree on the IDL definitions for an interface, then they are effectively operating with conflicting type systems and all hell breaks loose. So, I don't think the above scenario has any influence on the issue of substitutability. Cheers, Michi. Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Fri, 02 Oct 1998 19:27:50 -0400 From: Paul H Kyzivat Organization: NobleNet To: Michi Henning CC: Bill Janssen , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: Michi Henning wrote: > > I'm back from holidays, so I'm free to disagree with Paul again :-) You go away on vacation and come back early to spend your weekend harassing me :-) > I agree with the analysis. However, I think this scenario is simply > not > legal. Once an IDL type has been defined, it becomes immutable and > cannot > be changed. The scenario above really contains two "no-nos" as far > as > I can > see: > > - It changes an existing IDL type. > > - It uses different IDL definitions with identical > repository > IDs > for client and server. > > CORBA cannot cope with either of these. If an existing IDL type is > changed > in any way at all, clients may get surprises, as Paul points out. > There > are lots of ways to surprise the client, depending on exactly what > change is made. If client and server do not agree on the IDL > definitions > for an interface, then they are effectively operating with > conflicting > type systems and all hell breaks loose. > > So, I don't think the above scenario has any influence on the issue > of substitutability. I admit to ignoring a number of issues to focus on the point I was trying to make. I *think* the change is benign WRT interface A, but there are of course other issues. For instance M1 is changed. When you consider the overall picture I agree with you. But that doesn't change the major point that I was trying to make - namely that in the real world changes do need to be made. In fact, the OMG routinely just goes ahead and changes them. This leaves the vendors and the users to pick up the pieces, without any guidelines as to how. Many of the changes have been to pseudo-interfaces like ORB where we are to an extent allowed to cheat, but I am sure there are cases of real interfaces changing. And people are going to want a reasonable migration path, for both clients and servers. My example was partly based on an informal suggestion I heard at Seattle that I agree would be desirable: The current NamingContext interface in CosNaming defines both read and write type operations. There are cases where it would be desirable to build a read-only name service. (I think this was mixed in to some other service under development and was the basis for the suggestion.) To do a read-only implementation you must implement all the write operations and make them return some kind of error. This is not the best way to do it. Instead, it would be better if the NamingContext interface were factored into multiple interfaces, where one offers the read-only set of operations. This could be done so that the existing NamingContext interface still exists with the same set of operations, only now it gets some or all of them via inheritance. This would be an good kind of change, but how could it be rolled out? It would be silly to change the name and/or repository id of NamingContext, because that would break interoperation with all existing implementations - something that is not logically necessary. And this is just a small example. All the domain specifications that are coming forward will provide many more cases where non-disruptive evolution will be necessary. CORBA isn't going to be very popular if it can't offer a viable approach to evolution of distributed systems. We don't have to do it all at once, but it isn't helpful to deny that there is a problem. We at least ought to do better than COM does. It has an answer which is painful for developers, but at least you can imagine it working. (Keep defining new interfaces, while making your objects continue to support the old interfaces.) I have long considered the potential for redesigning the IDL and preserving key repository ids via #pragma as the beginnings of a CORBA solution, but that is just vapor until an attempt to really solve the problem. Return-Path: Date: Fri, 2 Oct 1998 16:38:10 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: Bill Janssen , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <36156176.281CC3E4@noblenet.com> Excerpts from direct: 2-Oct-98 Re: What does interface sub.. Paul H Kyzivat@noblenet. (4668*) > We at least ought to do better than COM does. It has an answer which is > painful for developers, but at least you can imagine it working. (Keep > defining new interfaces, while making your objects continue to support > the old interfaces.) Which is effectively the same inheritance answer which CORBA uses. Bill Return-Path: Date: Fri, 2 Oct 1998 16:55:39 PDT Sender: Bill Janssen From: Bill Janssen To: orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? References: Hi, Andrew :-). Excerpts from local.omg: 1-Oct-98 Re: What does interface sub.. Andrew Watson@omg.org (3784*) > I suggest we insert text in CORBA and/or the OMA to say something like this: > ... > When a client uses the DII to invoke an operation on a server, > ORB > implementations shall support interaction if the server provides > an operation whose name matches that given by the client, and all > corresponding supplied and formal parameters agree exactly in > type. > ... As always, I'm dismayed to see someone in Andrew's responsible position suggest changes such as this one. To begin with, the DII should serve the model, not the other way around. In my opinion, the DII is a haphazard and rather poorly designed way to deal with remote services -- wasn't it just recently we noticed it couldn't really return user exceptions? But more worrisome is the model of substitutability that this change suggests. We do away with interfaces and repository IDs, and use method substitutability based solely on the (laughably brief) method name and parameter types. Again in my opinion, this kind of thinking is exactly what holds CORBA back from being effective and robust enough for inter-enterprise and Internet-scale distributed computing. This low-level structural equivalence is simply not sufficient to safely distinguish between methods. However, a simple change would make it sufficient. That change is to add the repository ID of the interface type in which the method is defined to both the DII API, and to the GIOP request message. As I've noted before, the repository ID captures the semantic identity of the interface -- an identity which is important to correct selection of the method. By putting both the repository ID of the method, and the name of the method, in the request message, the server would at least have a fighting chance of understanding what the client intends it to do. In another message, Paul Kyzivat notes that we should be able to do better than DCOM. Note that DCOM doesn't make the ambiguity mistake; the UUID of the method's interface (DCOM's repository ID) is passed with the request. So CORBA doesn't even do as well as DCOM at the moment. Bill Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Sat, 3 Oct 1998 09:59:21 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Bill Janssen , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? Content-ID: On Fri, 2 Oct 1998, Paul H Kyzivat wrote: > You go away on vacation and come back early to spend your weekend > harassing me :-) Right. I couldn't think of anything better to do with my weekend :-) > But that doesn't change the major point that I was trying to make - > namely that in the real world changes do need to be made. In fact, > the > OMG routinely just goes ahead and changes them. This leaves the > vendors > and the users to pick up the pieces, without any guidelines as to > how. > Many of the changes have been to pseudo-interfaces like ORB where we > are > to an extent allowed to cheat, but I am sure there are cases of real > interfaces changing. And people are going to want a reasonable > migration > path, for both clients and servers. Completely agree. > My example was partly based on an informal suggestion I heard at Seattle > that I agree would be desirable: > > The current NamingContext interface in CosNaming defines both read and > write type operations. There are cases where it would be desirable to > build a read-only name service. (I think this was mixed in to some other > service under development and was the basis for the suggestion.) Yes, that would be useful. > To do a read-only implementation you must implement all the write > operations and make them return some kind of error. This is not the > best > way to do it. Instead, it would be better if the NamingContext > interface > were factored into multiple interfaces, where one offers the > read-only > set of operations. This could be done so that the existing > NamingContext > interface still exists with the same set of operations, only now it > gets > some or all of them via inheritance. > > This would be an good kind of change, but how could it be rolled > out? I don't think that is possible at all right now. For example, a client may have a dependency on the fact that NamingContext does *not* inherit from anything right now. Off-hand, it's hard to see how, but the fact that the interface is published and immutable entitles a client to make this assumption. This is similar to the example you showed earlier. Suppose for the moment we do what you suggest and derive NamingContext from a read-only and an update interface, using multiple inheritance. This leaves the actual NamingContext interface alone. Given that new NamingContext interface, the client can decide to pass only the read-only portion to some helper function, by calling narrow on the read-only interface. If we present such a client with the old version of NamingContext, that suddenly fails because the old (or original) NamingContext is *not* derived from anything. > It would be silly to change the name and/or repository id of > NamingContext, because that would break interoperation with all > existing > implementations - something that is not logically necessary. Yes. However, the repository ID is the one and only unique handle to the definition of a type. Change the type, and you *must* change the repository ID, otherwise the entire type system gets shot to all hell. > And this is just a small example. All the domain specifications that are > coming forward will provide many more cases where non-disruptive > evolution will be necessary. I agree -- there is a need for versioning and evolution of some kind, no doubt. However, CORBA doesn't have one. The words in the 2.2 spec about versioning were woefully inadequate though and completely ignored specifying the semantics of type compatibility in the presence of version number differences. They also completely ignored versioning in the presence of inheritance, which creates a whole new set of problems (and I am not sure that these problems are resolvable, even theoretically). > CORBA isn't going to be very popular if it can't offer a viable approach > to evolution of distributed systems. We don't have to do it all at once, > but it isn't helpful to deny that there is a problem. Yes. I believe that versioning and inheritance don't go together very well though. Every time I think about a versioning mechanism along the lines of DCE major/minor numbers, I run into serious problems with respect to inheritance and type compatibility. I suspect that any approach to this problem will have to use something like multiple interfaces instead -- as far as I can see, versioning and inheritance, when combined, create unresolvable semantic conflicts. > We at least ought to do better than COM does. It has an answer which is > painful for developers, but at least you can imagine it working. (Keep > defining new interfaces, while making your objects continue to support > the old interfaces.) I suspect that's the only approach that can actually work without semantic conflicts in the type system. > I have long considered the potential for redesigning the IDL and > preserving key repository ids via #pragma as the beginnings of a > CORBA > solution, but that is just vapor until an attempt to really solve > the > problem. Here are some things to think about then, to make a start: 1) #include (or similar) does not provide a way to select a particular version. However, I may have a dependency on a particular version. 2) What does it mean for "Derived" to inherit from "Base", if the version of "Base" goes up? Does "Derived" sort of "inherit" it's version from "Base"? If it does, what does it mean to increase the version number in the presence of multiple inheritance? 3) What if we have: // File1.idl interface Base { /* ... */ }; interface I1 : Base { /* ... */ }; // File2.idl interface Base { /* ... */ }; interface I2 : Base { /* ... */ }; // File3.idl #include "File1.idl" #include "File2.idl" interface Derived: I1, I2 { /* ... */ }; What if "Base" in File1.idl and File2.idl are different versions? 4) What if we have: interface Base { void op(); }; interface Derived Base { void op2(); }; Now the version of Base is changed such that it reads: interface Base { void op(); void op2(); }; What happens to interface Derived with this new version? There are lots more situation where inheritance and versioning interact in weird and wonderful ways. Unfortunately, I can't find anything like sensible semantics for any of them :-( Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Sat, 3 Oct 1998 10:05:36 +1000 (EST) From: Michi Henning To: Bill Janssen cc: orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? On Fri, 2 Oct 1998, Bill Janssen wrote: > > However, a simple change would make it sufficient. That change is > to > add the repository ID of the interface type in which the method is > defined to both the DII API, and to the GIOP request message. As > I've > noted before, the repository ID captures the semantic identity of > the > interface -- an identity which is important to correct selection of > the > method. By putting both the repository ID of the method, and the > name > of the method, in the request message, the server would at least > have a > fighting chance of understanding what the client intends it to do. > > In another message, Paul Kyzivat notes that we should be able to do > better than DCOM. Note that DCOM doesn't make the ambiguity > mistake; > the UUID of the method's interface (DCOM's repository ID) is passed > with > the request. So CORBA doesn't even do as well as DCOM at the > moment. I would strongly support such a change. It has bothered me for quite some time that certain type errors are completely undetectable due to the lack of a repository ID in a request. For example: interface foo { void op(in long l, in float f); }; If a client uses the DII to call op() and accidentally supplies the parameters in the wrong order, there is no way at all to catch the error. Instead, the bits of the long will be misinterpreted as the bits for the float and vice-versa. If I'm lucky, the misinterpretation would result in an NaN for the float, but there is no such guaranteed. If we had a repository ID on the wire with every request, such errors could be caught. In addition, it would make it substantially easier to build tools such as IIOP packet tracers -- right now, it is next to impossible to dump the parameter values of IIOP requests because the packet tracer has no way of figuring out what the type of the target object is. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Sender: andrew@emerald.omg.org References: Date: Fri, 2 Oct 1998 21:02:27 -0400 To: Bill Janssen From: Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org Bill, You wrote: > > I suggest we insert text in CORBA and/or the OMA to say something like > > this: > > > ... > > When a client uses the DII to invoke an operation on a server, ORB > > implementations shall support interaction if the server provides > > an operation whose name matches that given by the client, and all > > corresponding supplied and formal parameters agree exactly in type. > > ... > > As always, I'm dismayed to see someone in Andrew's responsible position > suggest changes such as this one. Whoa - hold your horses, Bill. While I'll happily return later to our never-ending theological debate on why structural (as opposed to inheritance-based) subtyping is the One True Way, right now I'm absolutely *not* trying to propose any changes. As I said in my last note: > B. Answering the question Jishnu posed, namely "what should go into the > OMA to reflect the reality of shipping products"? > > Regretfully leaving aside for now the chance to do battle in discussion > (A), I'd like to help bring some resolution to (B). The statement you quoted is an attempt to characterise what actual DII implementations actually do, so that we can craft some accurate text for the OMA and/or CORBA. If what I said is unrepresentative, and there are DII implementations that behave in other ways, I'd appreciate hearing about it so that we can adjust the text. However, I'm not doing this to gather ammunition for an argument, but only so that we can answer quation (B) and produce some words for an OMA that's consistent with CORBA products. > However, a simple change would make it sufficient. That change is to > add the repository ID of the interface type in which the method is > defined to both the DII API, and to the GIOP request message. Does any DII implementation do this? If it does, is it percieved to be in compliance with or in conflict with the CORBA specification? I ask these questions for information, rather than as rhetorical debating points. Trust me, there'll always be time for object theology later ... :-) Cheers, Andrew Return-Path: Date: Fri, 2 Oct 1998 19:18:57 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? CC: orb_revision@omg.org, ab@omg.org References: Excerpts from direct: 2-Oct-98 Re: What does interface sub.. Andrew Watson@omg.org (2154*) > Does any DII implementation do this? If it does, is it percieved to be in > compliance with or in conflict with the CORBA specification? Finally, a reason to implement the DII :-). Actually, it's not clear that the API to the DII would have to change. Given the current (and bad) restriction on method names, a DII implementation should be able to figure out which interface is being referred to given the object and method name, at the expense of increasing still further the computational inefficiency of the DII. The repository ID could be passed in a service context in the GIOP message, which would be backwards compatible. The real question, again, is what we say that the server should do with the information. If we allow the server to ignore the passed repository ID, have we really improved things? However, if say that the method to be invoked on the server should be determined by both the repository ID and the method name, we have added some real safety to the CORBA model. Bill Return-Path: Date: Fri, 2 Oct 1998 19:43:07 PDT Sender: Bill Janssen From: Bill Janssen To: Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? CC: orb_revision@omg.org, ab@omg.org References: Excerpts from direct: 2-Oct-98 Re: What does interface sub.. Andrew Watson@omg.org (2154*) > right now I'm absolutely *not* trying to propose any changes. I'm a tad confused (luckily a state I'm familiar with :-). Didn't your previous message contain this line (which I quoted): > I suggest we insert text in CORBA and/or the OMA to say something like this: Isn't this a change, at the very least to the text of the CORBA spec or the OMA? That's the thing I perceived to be a proposed change, and which I was objecting to. Bill Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Mon, 05 Oct 1998 11:51:54 +0200 To: "MILLER, Joaquin" From: Guy GENILLOUD Subject: RE: What does interface substitutability mean in CORBA? Cc: "'Andrew Watson'" , "'Jishnu Mukerji'" , "'orb_revision@omg.org'" , "'ab@omg.org'" At 08:27 AM 10/2/98 -0700, MILLER, Joaquin wrote: I've stayed out of this so far, but this seems like a good point to say two things. Joaquin Miller [Miller] Is it not the case that the OMG a l r e a d y has a theory of substitutability based on inheritance? See the section 4.4.6 of the OMA Guide. Hi Joaquin, You appear to be right, but read on... The text in section 4.4.6 says: When an object of type A is substitutable for an object of type B, A is said to be a subtype of B, and B a supertype of A. In the Core Object Model, all new types are specified in terms of existing types using inheritance. Inheritance in the Core Object Model is defined so that every type constructed by inheriting from another is automatically one of its subtypes. A type is defined to be a subtype of any type in the transitive closure of types from which it inherits, and is not a subtype of any type outside this transitive clo-sure. So far, subtyping is clearly defined to depend on inheritance. (I would not call this a theory for lack of a reference to rigorous work on such a type theory). However, section 4.4.6 appears to contradict itself. Its last paragraph says: Another shortcoming is that a new type must be defined as a subtype of an existing type, not as a supertype. This problem can usually be solved by inferring the subtype relationship by examining types, rather than having designers and programmers assert them. How can this problem be solved if the second paragraph of 4.4.6 holds? --- Note that the need of defining a supertype after a type has been defined is not just theoretical. Paul H Kyzivat just wrote: << My example was partly based on an informal suggestion I heard at Seattle that I agree would be desirable: The current NamingContext interface in CosNaming defines both read and write type operations. There are cases where it would be desirable to build a read-only name service. (I think this was mixed in to some other service under development and was the basis for the suggestion.) >> Being able to introduce supertypes of the NamingContext interface would solve this problem. --- Interestingly, section 4.4.6 also says that inheritance and subtyping are two different concepts. Although the Core Object Model effectively defines its inheritance to be the same as subtyping, the two concepts must be considered to be separate. Subtyping determines substitutability, whereas inheritance is a mechanism for specifying one entity in terms of another... --- In summary, I will contend that section 4.4.6 is invalid as it is, because it contradicts itself. At the very least, the contradiction must be resolved... Best regards Guy P.S. Another thing that bothers me, from a procedural perspective, is that this OMA text appears to have been written at about the time the same issue was debated in the CORBA RTF (with the RTF deciding not to make any change to the CORBA core). Changes were quietly made to the OMA w.r.t. a highly contentious issue at the time (it still is of course). Perhaps there was an attempt to resolve the on-going issue, but that attempt clearly failed (see the contradiction). -------------------------------------------------------------------- Dr. Guy Genilloud <http://icawww.epfl.ch/genilloud> Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Mon, 05 Oct 1998 12:29:43 +0200 To: "'orb_revision@omg.org'" , "'ab@omg.org'" From: Guy GENILLOUD Subject: RE: What does interface substitutability mean in CORBA? Dear all, I am sure everyone is as tired of this interface substitutability discussion as I am. However, we did learn a number of points and I'd like to make some of them here so that they don't get lost. The discussion is very much linked to the is_a operation. In fact, there are a number of points to be made w.r.t. this operation: 1) The parameter of is_a is conceptually a type, but in practice, it is a repository id. This raises a number of questions. 1.1 Can an object ignore a repository id that's submitted to it? (yes, for the following reasons: new supertype, other IR, ...) 2.2 How should an object answer the is_a question if it cannot find out the type referenced by a repository id? (YES and NO are both inappropriate answers) 2) is_a does not define substitutability. Not all clients systematically call is_a before they interact with an object. 2.1 What is a client allowed to do if is_a returns NO or an error? (in particular, if it is not mandatory to call is_a in the first place) 3) is_a is not the best way to provide type safety in a distributed objects platform. When is_a reveals a typing error, the error already occured... Why did not we catch that error when it occured? 4) The key to performance is in performing type checks when they are needed, not in calling is_a before using an interface. 5) is_a checks inheritance, or in other words "*implicit assertions* about the semantics of an interface." 5.1 Inheritance does not allow programmers to make any assertions about the semantics of a base interface... 5.2 Would'nt it be better if programmers could make *explicit assertions* about the semantics of an interface (see for example OMG 95-12-37) 6) Inheritance makes it difficult or impossible to define new supertypes of exiting types. Yet, this seems to be necessary. A case in point is a read-only supertype of the CosNaming service. 7) Inheritance rules in IDL may be seen as too restrictive. GDMO has more flexible inheritance rules than IDL, yet it is arguably stronger than IDL when it comes to verify substitutability. 7.1 Insistance of checking inheritance in IDL would impact interoperability with "GDMO object instances." I hope this will help. As I already said, my purpose here is that the OMG makes informed decisions. Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: From: N.P.Sharman@man0506.wins.icl.co.uk X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 5 Oct 1998 14:09:15 +0100 X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Mon, 5 Oct 1998 14:06:53 +0100 Date: Mon, 5 Oct 1998 14:06:53 +0100 X400-Originator: N.P.Sharman@man0506.wins.icl.co.uk X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;man0506 0000026100001161] X400-Content-Type: P2-1984 (2) Content-Identifier: 1161 Alternate-Recipient: Allowed Cc: "'orb_revision@omg.org'" , "'ab@omg.org'" References: <199810051028.MAA15634@dimail.epfl.ch> Subject: RE(2): What does interface substitutability mean in CORBA? Guy Genilloud writes: > Dear all, > > I am sure everyone is as tired of this interface substitutability > discussion as I am. However, we did learn a number of points and > I'd like to make some of them here so that they don't get lost. > > The discussion is very much linked to the is_a operation. > In fact, there are a number of points to be made w.r.t. this > operation: > > 1) The parameter of is_a is conceptually a type, but in practice, it > is > a repository id. This raises a number of questions. > > 1.1 Can an object ignore a repository id that's submitted to it? > (yes, for the following reasons: new supertype, other IR, ...) > I would say "no"; a repository id is supposed to identify a type unambiguously. As others have pointed out, adding a new supertype > gives you a new version of the type you started with, and it should have a different id, but CORBA doesn't handle type evolution convincingly. > If two IRs both contain information about "the same" type, then the two > repository ids should also be the same. > 2.2 How should an object answer the is_a question if it cannot find > out the type referenced by a repository id? > (YES and NO are both inappropriate answers) > As others have pointed out, compiled skeletons can contain a list of > all ids for which is_a returns TRUE. A dynamic skeleton could use a > similar list, or consult an IFR, or (if it is interposed between clients and a "real" implementation) delegate the task to the "real" object. It > seems reasonable to expect an object implemenataion to know its own point in > the inheritance graph. BTW, the list-of-ids approach means that we need > never involve the IFR for compiled skeletons (even those that, pace the Java mapping, sit atop the DSI), which must cover most cases. > > 2) is_a does not define substitutability. Not all clients > systematically > call is_a before they interact with an object. > Is_a can define substitutability if we want it to. I believe it's > entirely reasonable for an object implementation to say explicitly which > interface it implements (and by doing so to say that it also implements the supertypes). If it implements an interface that is unrelated by inheritance, but just happens to offer the "right" operations, then > that should be regarded as unintended coincidence. It's true that researchers are investigating other forms of substitutability (but I think these forms are often about the relationship between interface and implementation, which CORBA deliberately doesn't address), but that doesn't make it wrong to choose this simple form in this particular case. > 2.1 What is a client allowed to do if is_a returns NO or an error? > (in particular, if it is not mandatory to call is_a in the > first > place) > Nothing, probably. If we choose this model, then the C++ & Java > standards could make is_a a mandatory part of the _narrow operation, or could > make behaviour implementation & application dependent if is_a would have > failed (as it would have to anyway for C and SmallTalk). > > 3) is_a is not the best way to provide type safety in a distributed > objects platform. When is_a reveals a typing error, the error > already > occured... Why did not we catch that error when it occured? > Even in languages with fairly strong static type checking (Java & > C++), "downcasting" from supertype to subtype can "go wrong" at run time. > Up to the point of the "downcast", the object could legally have been one of several types, but we now want it to be one type in particular. At > least in a statically built language like C++, you know the full set of > types at link time; in a distributed system, one application may have no > knowledge of the other's subtype at all, so the client-side stubs for say the > Trader or Naming Service can't hope to construct a reference with type better > than CORBA::Object. In a sense, the point where we attempt to narrow an > object reference to the desired type is earliest point where we can be sure > an error has occurred. > > 4) The key to performance is in performing type checks when they are > needed, not in calling is_a before using an interface. > If we call is_a in the narrowing operation, we won't have to call it > before each operation. Similarly, a C programmer might call is_a just once > after retrieving a reference. > > 5) is_a checks inheritance, or in other words "*implicit assertions* > > about the semantics of an interface." > > 5.1 Inheritance does not allow programmers to make any assertions > about > the semantics of a base interface... > I think that they should be allowed to make that assumption: * if I define a new interface that derives from another, I am doing something more than just reusing the inherited operation text; * if I say in my server that I am implementing interface X (and all its base interfaces), then I should assume that other people will act on that promise. > 5.2 Would'nt it be better if programmers could make *explicit > assertions*> about the semantics of an interface (see for > example > OMG 95-12-37) > Well, it might, but two observations: - developers still seem highly resistant to formal specification; - checking specifications of any useful power (1st order predicate calculus) becomes undecidable; at least "is_a" can be made linear in number of base classes! > > 6) Inheritance makes it difficult or impossible to define new > supertypes > of exiting types. Yet, this seems to be necessary. A case in > point > is a read-only supertype of the CosNaming service. > Agreed (and for type evolution in general). > > 7) Inheritance rules in IDL may be seen as too restrictive. GDMO > has > more flexible inheritance rules than IDL, yet it is arguably > stronger > than IDL when it comes to verify substitutability. > Should we look to GDMO when defining CORBA 3.0 IDL? > 7.1 Insistance of checking inheritance in IDL would impact > interoperability with "GDMO object instances." > But do enough people care enough for this to matter? > > I hope this will help. > As I already said, my purpose here is that the OMG makes informed > decisions. > > Guy > > -------------------------------------------------------------------- > > Dr. Guy Genilloud > Institute for computer Communications and Applications (ICA) > Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 > > CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 > > -------------------------------------------------------------------- > > Nick Sharman Foxfield Software Ltd Return-Path: From: Ed Barkmeyer Date: Mon, 5 Oct 1998 11:24:53 -0400 (EDT) To: guy.genilloud@dimail.epfl.ch Subject: RE: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org X-Sun-Charset: US-ASCII Guy points out the critical problem: > The text in section 4.4.6 says: > > When an object of type A is substitutable for an object of type > B, > A is said to be a subtype of B, and B a supertype of A. (1) This clearly defines "subtype of" to mean "substitutable for". > In the Core Object Model, all new types are specified in terms of > existing types using inheritance. Inheritance in the Core Object > Model is defined so that every type constructed by inheriting > from > another is automatically one of its subtypes. (2) This says "Inherits from" implies "subtype of". > A type is defined to > be a subtype of any type in the transitive closure of types from > which it inherits, and is not a subtype of any type outside this > transitive clo-sure. (3) This says "subtype of" is equivalent to "transitively inherits from", and that "subtype of" is a transitive relationship. (It does not actually say that "inherits from" is a transitive relationship. I wonder if that was intentional.) Therefore from section 4.4.6, (1) and (3), we can deduce the following: An object of type A is substitutable for an object of type B if and only if type A transitively inherits from type B. So Andrew and I were both wrong! In order to allow ANY OTHER substitutability rule, we would have to change the Core Object Model. Guy goes on: > However, section 4.4.6 appears to contradict itself. Its last > paragraph > says: > > Another shortcoming is that a new type must be defined as a > subtype > of an existing type, not as a supertype. This problem can usually > be > solved by inferring the subtype relationship by examining types, > rather than having designers and programmers assert them. > > How can this problem be solved if the second paragraph of 4.4.6 > holds? There is a solution: Note that "inherits from" is NOT defined in 4.4.6. The idea that inheritance can be determined by "inferring the subtype relationship by examining types, rather than having designers ... assert them" means that the "inherits from" relationship need NOT be specified by declaration, i.e. IDL interface A : B! So the Core Object Model (4.4.6) currently equates "substitutability" to "subtype" and to "inheritance", but then apparently allows a very weak definition of inheritance -- including "observed inheritance" as well as "declared inheritance". Actually, nothing is wrong with this situation (sorry, Guy). Doing my Haim Kilov impersonation, I don't see a contradiction; I only see inadequately defined terms. In particular, the term "inheritance" has two importantly different meanings: the one in the Repository model (which I called "declared inheritance") and the one in the Core Object Model (which includes some kind of "observed inheritance" in addition to "declared inheritance"). The terms "subtype" and "inheritance" in the Repository model have MORE RESTRICTED MEANING than those of the Core Object Model. And what this really means is that Jishnu asked a confusing question. He asked whether substitutability was used in any way other than the "inheritance extension" model. In view of 4.4.6, the answer to that must be "no conforming implementation does". But what he really meant was: Does anyone use an inheritance notion different from that in the Repository model? And the answer to that seems to be: Yes, "observed inheritance" ("structural matching") is used as well. I would have to agree with Guy that what has been written to date is confusing, and we could make life a lot easier for the reader if we tried to avoid overloading terms. Overloading may be a "feature" in OOPLs, but it is clearly a "bug" in documentation. So we need to do one of three things: - Qualify the term "inheritance" everywhere. - Adopt the Repository model notion of "inheritance" and UNDO the equivalence of "substitutability" and "subtype" in the first sentence of 4.4.6. - Adopt the Repository model notion of "inheritance" and LEAVE the 3-way equivalence in 4.4.6 (satisfying the purists), and delete the "contradictory" sentence in 4.4.6 beginning "this problem can usually be solved" (and admit that it can't). In any case, we need to revise 4.4.6. As near as I can tell, Andrew's proposed solution presumes the second approach. In my view, that is the practical solution, although I lean toward the first, in order to avoid violating "the Law of Least Astonishment". -Ed "Can you read, sir?" "Aye, if I know the language and the alphabet." -- William Shakespeare, "Romeo and Juliet" Return-Path: Date: Mon, 05 Oct 1998 12:45:53 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bill Janssen CC: Michi Henning , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: <36156176.281CC3E4@noblenet.com> Bill Janssen wrote: > > Excerpts from direct: 2-Oct-98 Re: What does interface sub.. Paul H > Kyzivat@noblenet. (4668*) > > > We at least ought to do better than COM does. It has an answer > which > is > > painful for developers, but at least you can imagine it working. > (Keep > > defining new interfaces, while making your objects continue to > support > > the old interfaces.) > > Which is effectively the same inheritance answer which CORBA uses. > > Bill I disagree that this is the same as CORBA with inheritance. Suppose in COM, I have an interface IFoo with an operation that has some signature, and I decide that the signature is a mistake and needs to be changed. I think the politically correct way to do this is to define a new interface IFoo2 that is the same as the old one except for the signature change I want to make. Then I change servers of IFoo to also respond to QueryInterface for IFoo2 for the same object. In CORBA I can't do this. If interface Foo has the signature one way then I can't make a derived interface with a changed signature. If I make a separate Foo2 interface not related by inheritance then a single object instance will not return TRUE for is_a requests on the repository ids of both Foo and Foo2. I don't much like the COM approach. It places an inordinate ongoing burden on both clients and servers to deal with interface evolution. But at the moment it seems better than the (non-)approach in CORBA. Return-Path: Date: Mon, 05 Oct 1998 13:00:44 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bill Janssen CC: orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? References: Bill Janssen wrote: > However, a simple change would make it sufficient. That change is to > add the repository ID of the interface type in which the method is > defined to both the DII API, and to the GIOP request message. As I've > noted before, the repository ID captures the semantic identity of the > interface -- an identity which is important to correct selection of > the > method. By putting both the repository ID of the method, and the name > of the method, in the request message, the server would at least have > a > fighting chance of understanding what the client intends it to do. If a change is to be made, why not change to allow *either* the name or the repository ID of the method? Then eventually use of the name could be deprecated. Return-Path: Date: Mon, 05 Oct 1998 13:17:17 -0400 From: Paul H Kyzivat Organization: NobleNet To: Michi Henning CC: Bill Janssen , orb_revision@omg.org, ab@omg.org Subject: Re: What does interface substitutability mean in CORBA? References: Michi Henning wrote: > I would strongly support such a change. It has bothered me for quite > some > time that certain type errors are completely undetectable due to the > lack > of a repository ID in a request. For example: > > interface foo { > void op(in long l, in float f); > }; > > If a client uses the DII to call op() and accidentally supplies the > parameters > in the wrong order, there is no way at all to catch the error. > Instead, > the bits of the long will be misinterpreted as the bits for the > float > and > vice-versa. If I'm lucky, the misinterpretation would result in an > NaN > for the float, but there is no such guaranteed. > > If we had a repository ID on the wire with every request, such > errors > could > be caught. In addition, it would make it substantially easier to > build > tools such as IIOP packet tracers -- right now, it is next to > impossible > to dump the parameter values of IIOP requests because the packet > tracer > has no way of figuring out what the type of the target object is. There is already partial support for this in GIOP 1.2. It is now possible to send the object reference with the request instead of just the key, and it is ok for the server to demand that it be sent. If it is sent, and assuming it contains the repository id, then there is sufficient information for packet tracers. However this doesn't guarantee that the sender had the same understanding of the interface that the receiver does. Having the sender provide independently deduced information about the operation it intends to invoke provides slightly more assurance, but is no guarantee. Return-Path: Date: Mon, 5 Oct 1998 10:20:41 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: Michi Henning , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <36156176.281CC3E4@noblenet.com> <3618F7C0.AFE2E71C@noblenet.com> Excerpts from direct: 5-Oct-98 Re: What does interface sub.. Paul H Kyzivat@noblenet. (2288*) > In CORBA I can't do this. If interface Foo has the signature one way > then I can't make a derived interface with a changed signature. If I > make a separate Foo2 interface not related by inheritance then a > single > object instance will not return TRUE for is_a requests on the > repository > ids of both Foo and Foo2. Yes, but you can relate Foo and Foo2 by inheriting them both into a ``dummy'' interface Foo3, thus allowing one interface which contains both of them. It's true that Foo and Foo2 must call the method (and all their other methods) by different names -- this is another evil side-effect of the interface ambiguity in IIOP thought by some to be a useful idea. Bill Return-Path: Date: Mon, 5 Oct 1998 10:21:45 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: orb_revision@omg.org, ab@omg.org References: <3618FB3C.985683FF@noblenet.com> Why allow something we plan to deprecate anyway? Why not do it right to begin with? A radical idea for the CORBA community, I know... :-). Bill Return-Path: Date: Mon, 05 Oct 1998 14:29:09 -0400 From: Paul H Kyzivat Organization: NobleNet To: Michi Henning CC: Bill Janssen , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: Michi Henning wrote: [snip] > I don't think that is possible at all right now. For example, [snip] You make a number of good arguments. I don't disagree with them. But it doesn't alter the practical necessity to evolve IDL in a way that is not disruptive to clients and servers that have already been deployed. > I agree -- there is a need for versioning and evolution of some kind, > no doubt. However, CORBA doesn't have one. The words in the 2.2 spec > about versioning were woefully inadequate though and completely > ignored > specifying the semantics of type compatibility in the presence of > version number differences. They also completely ignored versioning > in the presence of inheritance, which creates a whole new set of > problems > (and I am not sure that these problems are resolvable, even > theoretically). It appears to me that both minor version upward compatibility and the details of how pragma prefix work were intended to provide (some of) the means to evolve IDL in a non-disruptive way. However it seems that the details were never worked out and those hooks are most likely insufficient for the job. > > We at least ought to do better than COM does. It has an answer which > is > > painful for developers, but at least you can imagine it working. > (Keep > > defining new interfaces, while making your objects continue to > support > > the old interfaces.) > > I suspect that's the only approach that can actually work without > semantic > conflicts in the type system. Perhaps, but I hope not. > Here are some things to think about then, to make a start: > > 1) #include (or similar) does not provide > a way to select a particular version. However, I may have > a dependency on a particular version. > > 2) What does it mean for "Derived" to inherit from "Base", > if > the version of "Base" goes up? Does "Derived" sort of > "inherit" > it's version from "Base"? If it does, what does it mean > to > increase the version number in the presence of multiple > inheritance? > > 3) What if we have: > > // File1.idl > interface Base { /* ... */ }; > interface I1 : Base { /* ... */ }; > > // File2.idl > interface Base { /* ... */ }; > interface I2 : Base { /* ... */ }; > > // File3.idl > #include "File1.idl" > #include "File2.idl" > > interface Derived: I1, I2 { /* ... */ }; > > What if "Base" in File1.idl and File2.idl are different > versions? > > 4) What if we have: > > interface Base { > void op(); > }; > > interface Derived Base { > void op2(); > }; > > Now the version of Base is changed such that it reads: > > interface Base { > void op(); > void op2(); > }; > > What happens to interface Derived with this new version? > > There are lots more situation where inheritance and versioning > interact > in weird and wonderful ways. Unfortunately, I can't find anything > like > sensible semantics for any of them :-( You give some interesting problems. Many of the problems you give are build-time compatibility issues. I would be willing to impose harsher rules on this than on run-time substitutability. Perhaps separating the two problems would allow the simpler one to be solved. (On the other hand, when you start downloading code at runtime the distinction starts to become irrelevant.) I think perhaps it is time to end this thread, or at least my participation in it. This is mostly idle speculation now. While I consider the problem important I just don't have the time to work on it now. Return-Path: Date: Mon, 05 Oct 1998 14:50:15 -0400 From: Paul H Kyzivat Organization: NobleNet To: Bill Janssen CC: Michi Henning , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller Subject: Re: What does interface substitutability mean in CORBA? References: <36156176.281CC3E4@noblenet.com> <3618F7C0.AFE2E71C@noblenet.com> Bill Janssen wrote: > > Excerpts from direct: 5-Oct-98 Re: What does interface sub.. Paul H > Kyzivat@noblenet. (2288*) > > > In CORBA I can't do this. If interface Foo has the signature one > way > > then I can't make a derived interface with a changed signature. If > I > > make a separate Foo2 interface not related by inheritance then a > single > > object instance will not return TRUE for is_a requests on the > repository > > ids of both Foo and Foo2. > > Yes, but you can relate Foo and Foo2 by inheriting them both into a > ``dummy'' interface Foo3, thus allowing one interface which contains > both of them. It's true that Foo and Foo2 must call the method (and > all > their other methods) by different names -- this is another evil > side-effect of the interface ambiguity in IIOP thought by some to be > a > useful idea. Great! So because I want to change the signature of one operation I must make a new interface with a new name and then rename both the changed operation and all the unchanged ones! After a few iterations of changes all the operation names will begin to look as mnemonic as UUIDs. And any client that needs to deal with multiple versions of the same interface must replicate the code that makes the calls, even to unchanged operations, using different names and references. This is too unspeakably ugly for words! There at least needs to be a way for most of the mess to be handled by a code generator. Return-Path: Date: Mon, 5 Oct 1998 12:07:56 PDT Sender: Bill Janssen From: Bill Janssen To: Michi Henning , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: Bill Janssen , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller , spreitzer.PARC@xerox.com References: <36190FF5.ABC4D5BF@noblenet.com> Excerpts from direct: 5-Oct-98 Re: What does interface sub.. Paul H Kyzivat@noblenet. (4794*) > But it doesn't alter the practical necessity to evolve IDL in a way that > is not disruptive to clients and servers that have already been > deployed. My colleague, Mike Spreitzer, has been working on just such a technology for the HTTP-NG project. We hope to have something published on his approach in the not-to-distant future. I'll send out a pointer to orb_revision when it happens. Bill Return-Path: Date: Mon, 5 Oct 1998 12:11:52 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Paul H Kyzivat Subject: Re: What does interface substitutability mean in CORBA? CC: Michi Henning , Guy GENILLOUD , Jishnu Mukerji , orb_revision@omg.org, ab@omg.org, Joaquin Miller References: <36156176.281CC3E4@noblenet.com> <3618F7C0.AFE2E71C@noblenet.com> <361914E7.BF3DD8FE@noblenet.com> Excerpts from direct: 5-Oct-98 Re: What does interface sub.. Paul H Kyzivat@noblenet. (2273*) > This is too unspeakably ugly for words! Yep. Most of the trouble, though, is caused by more-or-less useless but carefully maintained use, in CORBA, of method names (instead of interface-ID/method-name pairs) to identify operations. Bill Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Tue, 06 Oct 1998 11:38:13 +0200 To: N.P.Sharman@man0506.wins.icl.co.uk From: Guy GENILLOUD Subject: RE(2): What does interface substitutability mean in CORBA? Cc: "'orb_revision@omg.org'" , "'ab@omg.org'" At 02:06 PM 10/5/98 +0100, Nick P.Sharman wrote (>>): >Guy Genilloud wrote: Nick, We favor different options, but anyway, my main goal now is clarification. Obviously, I did not quite succeed. I mainly respond to clarify what I wrote in my previous message. >> 1) The parameter of is_a is conceptually a type, but in practice, it is >> a repository id. This raises a number of questions. >> >> 1.1 Can an object ignore a repository id that's submitted to it? >> (yes, for the following reasons: new supertype, other IR, ...) >> >I would say "no"; a repository id is supposed to identify a type >unambiguously. As others have pointed out, adding a new supertype gives >you a new version of the type you started with, and it should have a >different id, but CORBA doesn't handle type evolution convincingly. If two >IRs both contain information about "the same" type, then the two repository >ids should also be the same. What I meant to say is: - *Is it at all possible* for an object to ignore a repository id that's submitted to it (given that there is not just one IR, etc.)? If the answer is indeed NO, then it is easy to implement the is_a method at the skeleton level. If the answer is YES, then is_a may need to return an error, rather than TRUE or FALSE. >> >> 2) is_a does not define substitutability. Not all clients >> systematically >> call is_a before they interact with an object. >> >Is_a can define substitutability if we want it to. The current text in the OMA, section 4.4.4, defines substitutable as: Interface A is *substitutable* for interface B if a client that expects to use an object presenting interface B can get and use a reference to an object with interface A. This must occur without an interaction error. (See also the def'n of *interaction error*). Add to this definition that calling is_a is NOT mandatory for an interaction to take place, and you get a pretty clear idea of what substitutability practically means in CORBA today. How would you redefine substitutability on the basis of is_a? How would you enforce it? >I believe it's entirely >reasonable for an object implementation to say explicitly which interface >it implements (and by doing so to say that it also implements the >supertypes). If it implements an interface that is unrelated by >inheritance, but just happens to offer the "right" operations, then that >should be regarded as unintended coincidence. I understand this argument. Note that no matter how you define typing and subtyping, *application errors* will always remain possible. Preventing errors means making strong checks. Making strong assertions is not enough. >It's true that researchers are investigating other forms of >substitutability (but I think these forms are often about the relationship >between interface and implementation, which CORBA deliberately doesn't >address), but that doesn't make it wrong to choose this simple form in this >particular case. For clarification, I am not aware of any serious theory of typing that retains interface inheritance (that does not mean that there is no such theory). >> 2.1 What is a client allowed to do if is_a returns NO or an error? >> (in particular, if it is not mandatory to call is_a in the >> first >> place) >> >Nothing, probably. If we choose this model, then the C++ & Java >> standards >could make is_a a mandatory part of the _narrow operation, or could >> make >behaviour implementation & application dependent if is_a would have >> failed >(as it would have to anyway for C and SmallTalk). I agree, but this in not enforced today. >> 3) is_a is not the best way to provide type safety in a distributed >> objects platform. When is_a reveals a typing error, the error already >> occured... Why did not we catch that error when it occured? >> >Even in languages with fairly strong static type checking (Java & C++), >"downcasting" from supertype to subtype can "go wrong" at run time. Up to >the point of the "downcast", the object could legally have been one of >several types, but we now want it to be one type in particular. At least >in a statically built language like C++, you know the full set of types at >link time; in a distributed system, one application may have no knowledge >of the other's subtype at all, so the client-side stubs for say the Trader >or Naming Service can't hope to construct a reference with type better than >CORBA::Object. In a sense, the point where we attempt to narrow an object >reference to the desired type is earliest point where we can be sure an >error has occurred. Right. My point is about typed interface parameters. As far as I know, these are not systematically checked or enforced. A simplistic way to check an interface, received as a typed parameter, would be to call is_a just before using it. But as I said, if is_a returns false, it catches a type error that was done earlier. There is no big benefit in catching an error so late. >> 4) The key to performance is in performing type checks when they are >> needed, not in calling is_a before using an interface. >> >If we call is_a in the narrowing operation, we won't have to call it before >each operation. Similarly, a C programmer might call is_a just once after >retrieving a reference. See point 3 above. >> >> 5) is_a checks inheritance, or in other words "*implicit >> assertions* >> about the semantics of an interface." >> >> 5.1 Inheritance does not allow programmers to make any assertions >> about >> the semantics of a base interface... >> >I think that they should be allowed to make that assumption: > >* if I define a new interface that derives from another, I am doing > something more than just reusing the inherited operation text; > >* if I say in my server that I am implementing interface X (and all >> its > base interfaces), then I should assume that other people will act >> on > that promise. > >> 5.2 Would'nt it be better if programmers could make *explicit >> assertions*> about the semantics of an interface (see for >> example >> OMG 95-12-37) >> >Well, it might, but two observations: >- developers still seem highly resistant to formal specification; >- checking specifications of any useful power (1st order predicate > calculus) becomes undecidable; at least "is_a" can be made linear >> in > number of base classes! OMG 95-12-37 is a practical proposition, that would complement the service properties associated to a type in the trader... >> 6) Inheritance makes it difficult or impossible to define new supertypes >> of exiting types. Yet, this seems to be necessary. A case in point >> is a read-only supertype of the CosNaming service. >> >Agreed (and for type evolution in general). Making subtyping independent of inheritance is the only solution that I am aware of. Solutions that preserve inheritance are certainly possible, but are they practical. >> >> 7) Inheritance rules in IDL may be seen as too restrictive. GDMO has >> more flexible inheritance rules than IDL, yet it is arguably stronger >> than IDL when it comes to verify substitutability. >> >Should we look to GDMO when defining CORBA 3.0 IDL? You would need to be careful and to have a clear idea of typing. GDMO aims to do good but ends up being inconsistent here and there -- the result is application errors, nearly interaction errors. This being said, IDL does not prevent such inconsistencies to be made (GDMO to IDL just brings inconsistencies in IDL). See the section on inconsistent subytypes in my PhD thesis. GDMO is also interesting for its extensive use of global OIDs. For procedural or other reasons, some types were sometimes allocated different global OIDs (1 type, several OIDs) There is no fully satisfactory way to resolve the resulting problem. > >> 7.1 Insistance of checking inheritance in IDL would impact >> interoperability with "GDMO object instances." >> >But do enough people care enough for this to matter? Maybe. If something works today but will not tomorrow, some people will care a lot. What I was trying to say here is that the more constraints on the CORBA side, the more difficult it is to interoperate with other object based systems. Best regards Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) tel: +41 21 693 46 57 CH-1015 Lausanne, SWITZERLAND fax: +41 21 693 47 01 -------------------------------------------------------------------- Return-Path: X-Sender: andrew@emerald.omg.org (Unverified) References: Date: Tue, 6 Oct 1998 18:08:46 -0400 To: Bill Janssen From: Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? Cc: orb_revision@omg.org, ab@omg.org Bill, You wrote: > > right now I'm absolutely *not* trying to propose any changes. > > I'm a tad confused (luckily a state I'm familiar with :-). Didn't your > previous message contain this line (which I quoted): > > > I suggest we insert text in CORBA and/or the OMA to say something like > > this: > > Isn't this a change, at the very least to the text of the CORBA spec or > the OMA? Sorry, there was indeed some loose terminology there. I am proposing that we identify as accurately as possible the model as implemented by the generality of CORBA products, then alter the wording of the OMA and/or CORBA specification so that they describe that model better than they do at present. Hence I am *not* proposing changes to the behaviour of CORBA implementations, but I *am* proposing changes to the text so that it describes that behaviour more closely. > That's the thing I perceived to be a proposed change, and > which I was objecting to. Why is it undesirable to improve the specifications so that they describe the implmentations more precisely? Cheers, Andrew Return-Path: Date: Tue, 6 Oct 1998 17:26:03 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? CC: orb_revision@omg.org, ab@omg.org References: Excerpts from direct: 6-Oct-98 Re: What does interface sub.. Andrew Watson@omg.org (1164*) > Why is it undesirable to improve the specifications so that they describe > the implmentations more precisely? Because the behavior of the implementations may have been shaped by sub-optimal features in the specifications. Better, in my opinion, to fix the specifications to what's really needed, and let the implementations eventually conform, than to model the spec on sub-optimal implementations. Bill Return-Path: Date: Wed, 7 Oct 1998 17:59:19 PDT Sender: Bill Janssen From: Bill Janssen To: Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? CC: orb_revision@omg.org, ab@omg.org References: Excerpts from local.omg: 1-Oct-98 Re: What does interface sub.. Andrew Watson@omg.org (3784*) > B. Answering the question Jishnu posed, namely "what should go into the OMA > to reflect the reality of shipping products"? > Regretfully leaving aside for now the chance to do battle in discussion > (A), I'd like to help bring some resolution to (B). > I suggest we insert text in CORBA and/or the OMA to say something like this: > [ ... ] > Something like this seems to me to reflect what the range of real products > does. It allows C and Smalltalk ORBs implementing the broad definition of > substitutability to be compliant without making C++ ORBs that use an is_a > substitutability test be non-compliant. The language could certainly do > with cleaning up - especially the DII paragraph, which fails to say how the > server operations are defined (IDL? DSI?) and what "matches" means. But > it's a start. Andrew, I believe that the change you propose would in fact bring the OMA into clearer alignment with the reality of shipping products. I'd like to make it clear to everyone that I respect your integrity in making this suggestion, and I believe that you believed it to be a helpful, constructive step -- just in case anyone thought otherwise. What I was trying to say last week was that I don't think it's a good idea, and I hoped that you wouldn't think it was a good idea, either. I think in general it's a bad idea to modify the specification to match the shipping code base, particularly when `the reality of shipping products' is flawed. My quarrel is really with Jishnu, apparently, who suggested modifying the OMA to reflect the reality of shipping products. Bill Return-Path: Date: Wed, 7 Oct 1998 18:02:42 PDT Sender: Bill Janssen From: Bill Janssen To: Jishnu Mukerji , Andrew Watson Subject: Re: What does interface substitutability mean in CORBA? CC: orb_revision@omg.org, ab@omg.org References: Excerpts from local.omg: 1-Oct-98 Re: What does interface sub.. Andrew Watson@omg.org (3784*) > A. A theological, er sorry *theoretical*, debate on how things should be in > an ideal world. I'll happily pitch in with my usual opinions, which > roughly speaking means siding with Ed, Guy and Steve against the Forces > of Darkness (Hello Bill :-). (Incidentally, there are no prizes for > guessing who originally wrote the text Joaquin quoted from the OMA). Sorry, folks. I'm not going to give up on this :-). I also refuse to see it as a theological argument. It has real negative engineering side-effects which, in my opinion, seriously affect the ability of CORBA to be used in the ways in which Xerox would like to use it. These effects seem to have no balancing advantages. I see this as a discussion about the capabilities of CORBA, and I'd prefer to discuss it as such. Bill Return-Path: From: "MILLER, Joaquin" To: "'Bill Janssen'" Cc: "'orb_revision@omg.org'" , "'ab@omg.org'" , "OMG OMA Guide (E-mail)" Subject: RE: What does interface substitutability mean in CORBA? Date: Thu, 8 Oct 1998 10:15:19 -0500 I wont' do the research to figure out what Jishnu suggested, but i don't remember him suggesting anything, but rather asking a question. His question was prompted by a question from me to him, which was: "What does the current CORBA model have to say on the subject of interface substitutability? [Not what the text of the 2.3 document says, but what the ORB vendors think 'substitutability' means.]" My requirement is that the new OMG Core Object Model be able to specify both --what the CORBA spec says and --what the vendors deliver. Joaquin Miller >-----Original Message----- >From: Bill Janssen [SMTP:janssen@parc.xerox.com] >Sent: Wednesday, October 07, 1998 7:59 PM > >... >What I was trying to say last week was that I don't think it's a good >idea, and I hoped that you wouldn't think it was a good idea, either. I >think in general it's a bad idea to modify the specification to match >the shipping code base, particularly when `the reality of shipping >products' is flawed. My quarrel is really with Jishnu, apparently, who >suggested modifying the OMA to reflect the reality of shipping products. > >Bill > > Sender: jis@fpk.hp.com Message-ID: <3814C34A.C61EFD9@fpk.hp.com> Date: Mon, 25 Oct 1999 16:53:30 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 1997 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 6H^d9b#F!!n20!!B^?e9 Issue 1997: What does interface substitutability mean in CORBA? (orb_revision) Click here for this issue's archive. Source: Hewlett-Packard (Dr. Jishnu Mukerji, jis@fpk.hp.com) Nature: Uncategorized Issue Severity: Summary: Thanks to Joaquin Miller, a question came up in the context of the OMA revision work that is going on in ORMSC about what the ORB vendors think 'substitutability' means. Resolution: Revised Text: Actions taken: September 29, 1998: received issue ________________________________________________________________ Resolution: The only form of type substitutabillity that is know to work across the board in the CORBA world is one wherein a reference to an interface whose most derived type is D can be passed where a reference to an interface of type B is expected if and only if B is a base interface of D. That's the Liskov substitution principle (well, Barbara can say it more elegantly than I can ;-), and it works. Moreover, it's the only notion of type substitutability that has been implemented in ORBs. Whether to catch a type mismatch at compile time or run time is a language mapping issue. Revised Text: In section 1.2.5 "Interfaces" append the following paragraph: "Interfaces satisfy the Liskov subsitution principle. That is a reference to an interface whose most derived type is D can be passed where a reference to an interface of type B is expected if and only if B is a base interface of D." ______________________________________________________________ I think that is about as much as we can say about substitutability in CORBA. Yes, there may be other kinds that someone might dream up including operations signature based substituability of operations and set of operations based substitutability of interfaces, but in practice all those are of esoteric theoretical interest, and people can continue to do research and publish papers. OK, now five times charmed chain mail one and duck.:-) We will vote on this in the lifetime of this RTF.:-) Comments? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Mon, 25 Oct 1999 19:23:15 -0400 From: Paul H Kyzivat Organization: NobleNet X-Mailer: Mozilla 4.0 [en] (WinNT; I) MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 1997 X-Priority: 3 (Normal) References: <3814C34A.C61EFD9@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :D^d9MJ1!!?~\!!3W'!! Jishnu Mukerji wrote: > > Issue 1997: What does interface substitutability mean in CORBA? > (orb_revision) [snip] > OK, now five times charmed chain mail one and duck.:-) We will vote > on > this in the lifetime of this RTF.:-) > > Comments? Let's do it. Date: Tue, 02 Nov 1999 16:05:28 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "Juan J. Hierro" CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <381ECB42.6E5B33F8@tid.es> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: @#(e9jX5!!MZjd9Q]jd9 Juan, "Juan J. Hierro" wrote: > > + ABSTAIN on 1997 but want to propose the following amendment: > > use of term 'object' instead of 'interface' in some parts of > the paragraph because (at least in my mind :-) you may > have references 'to objects' but not 'to interfaces'. My > proposed text would be: > > "Interfaces satisfy the Liskov subsitution principle. That is > a reference to an object whose most derived type is D can be > passed where a reference to an object of type B is expected > if and only if B is a base interface of D." > > If the amendment is approved, then I would change my vote to > YES. > I don't think the above is correct. The substitutability rules > described here are for interface types defined at compile time in method > signatures, not for objects which are run-time embodiments of those interfaces. > Object substitutability is not confined to a strictly hierarchical > inheritance relationship. So I would like to leave the original words unchanged. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <381F2DD2.401C130C@fpk.hp.com> Date: Tue, 02 Nov 1999 13:30:42 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: "Juan J. Hierro" , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <381ECB42.6E5B33F8@tid.es> <381F0BC8.8179997C@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2nKe9U%Ee9OUA!!% > Juan, > > "Juan J. Hierro" wrote: > > > > + ABSTAIN on 1997 but want to propose the following amendment: > > > > use of term 'object' instead of 'interface' in some parts of > > the paragraph because (at least in my mind :-) you may > > have references 'to objects' but not 'to interfaces'. My > > proposed text would be: > > > > "Interfaces satisfy the Liskov subsitution principle. That is > > a reference to an object whose most derived type is D can be > > passed where a reference to an object of type B is expected > > if and only if B is a base interface of D." > > > > If the amendment is approved, then I would change my vote to > > YES. > > > I don't think the above is correct. The substitutability rules > described > here are for interface types defined at compile time in method > signatures, > not for objects which are run-time embodiments of those interfaces. > Object > substitutability is not confined to a strictly hierarchical > inheritance > relationship. So I would like to leave the original words > unchanged. I agree strongly with Simon. I would have to vote against the modified language proposed above for reasons aptly presented by Simon, if it were brought to vote. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Posted-Date: Wed, 3 Nov 1999 14:49:12 +0100 (MET) Message-ID: <38203D63.3D0A84F7@tid.es> Date: Wed, 03 Nov 1999 14:49:23 +0100 From: "Juan J. Hierro" Organization: Telefonica I+D X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: nick.sharman@peerlogic.com CC: Simon Nash , Jishnu Mukerji , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <003801bf25f6$bb55ad00$5610a8c0@thumper.uk.peerlogic.com> Content-Type: multipart/mixed; boundary="------------B232BCD3ECB6B057DC948006" X-UIDL: J1Ee943A!!>g4!!-6D!! Nick Sharman wrote: > > Simon Nash wrote: > > > > Juan, > > > > "Juan J. Hierro" wrote: > > > > > > + ABSTAIN on 1997 but want to propose the following amendment: > > > > > > use of term 'object' instead of 'interface' in some parts of > > > the paragraph because (at least in my mind :-) you may > > > have references 'to objects' but not 'to interfaces'. My > > > proposed text would be: > > > > > > "Interfaces satisfy the Liskov subsitution principle. That is > > > a reference to an object whose most derived type is D can be > > > passed where a reference to an object of type B is expected > > > if and only if B is a base interface of D." > > > > > > If the amendment is approved, then I would change my vote to > > > YES. > > > > > I don't think the above is correct. The substitutability rules > described > > here are for interface types defined at compile time in method > signatures, > > not for objects which are run-time embodiments of those > > interfaces. Object > > substitutability is not confined to a strictly hierarchical > inheritance > > relationship. So I would like to leave the original words > unchanged. > > > > Simon > > Surely Juan is right in saying that you can't have references to > interfaces > [types], only objects [instances of types]? I understood Juan's > suggestion > to be merely tightening up the type/instance looseness that most of > us fall > into informally. > Ok !!! you are right. The nature of my comment was exactly the one you explain above. My understanding of the CORBA model is that you have references to object exporting interfaces, not references to interfaces. I understand the difference is subtle (forgive my poor english, I hope subtle is the word, 'sutil' in spanish :-) but I believe there exists ... > One question is: does a CORBA object have a single most-derived type? I > think the answer is "YES" - and that ties in with (in the CCM) a component's > facets all being objects distinct from each other and the component itself. > (This doesn't forbid a single servant implementing two objects of unrelated > type, but that's different.) > I also believe that the answer is YES. Under that premise I formulated the alternative text. > If so, then when could a D-instance be passed where a B-instance is > expected, when D _doesn't_ derive from B? I.e, can you supply an > example > where Juan's rule can be broken while maintaining the original rule? > Thanks Nick for your help, -- Juanjo [] vcard.vcf Date: Wed, 03 Nov 1999 18:11:59 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: nick.sharman@peerlogic.com CC: "Juan J. Hierro" , Jishnu Mukerji , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <003801bf25f6$bb55ad00$5610a8c0@thumper.uk.peerlogic.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ':1e9#Rd!!"oed9+>De9 Nick, Nick Sharman wrote: > > Simon Nash wrote: > > > > Juan, > > > > "Juan J. Hierro" wrote: > > > > > > + ABSTAIN on 1997 but want to propose the following amendment: > > > > > > use of term 'object' instead of 'interface' in some parts of > > > the paragraph because (at least in my mind :-) you may > > > have references 'to objects' but not 'to interfaces'. My > > > proposed text would be: > > > > > > "Interfaces satisfy the Liskov subsitution principle. That is > > > a reference to an object whose most derived type is D can be > > > passed where a reference to an object of type B is expected > > > if and only if B is a base interface of D." > > > > > > If the amendment is approved, then I would change my vote to > > > YES. > > > > > I don't think the above is correct. The substitutability rules > described > > here are for interface types defined at compile time in method > signatures, > > not for objects which are run-time embodiments of those > > interfaces. Object > > substitutability is not confined to a strictly hierarchical > inheritance > > relationship. So I would like to leave the original words > unchanged. > > > > Simon > > Surely Juan is right in saying that you can't have references to > interfaces > [types], only objects [instances of types]? I understood Juan's > suggestion > to be merely tightening up the type/instance looseness that most of > us fall > into informally. > > One question is: does a CORBA object have a single most-derived > type? I > think the answer is "YES" - and that ties in with (in the CCM) a > component's > facets all being objects distinct from each other and the component > itself. > (This doesn't forbid a single servant implementing two objects of > unrelated > type, but that's different.) > > If so, then when could a D-instance be passed where a B-instance is > expected, when D _doesn't_ derive from B? I.e, can you supply an > example > where Juan's rule can be broken while maintaining the original rule? > Here's one counterexample: interface A { void amethod(); }; interface C { void cmethod(); }; interface B: A, C {}; interface D: A, C {}; interface X { void foo(in A myObj); }; My implementation of foo may *expect* to receive an object of type B (i.e., an object with the functionality of both the A and C interfaces). It may never have heard of type D. However, a reference to an object of type D *can* be passed to method foo, and this will work if my method foo was implemented to refer only to the A and C interfaces and not the B interface, even though B is not a base interface of D. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jis@fpk.hp.com Message-ID: <3822F28D.9D7524D5@fpk.hp.com> Date: Fri, 05 Nov 1999 10:06:54 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Jonathan Biggar Cc: orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <382226C6.D969C213@floorboard.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E1i!!!iE!!MR-e9D$De9 Jonathan Biggar wrote: > 1997: I agree with Juan that the wording isn't right, but I don't agree > with his counterproposal either. There is no such thing as a reference > to an interface, only references to an object. Try this instead: > > "Interfaces satisfy the Liskov subsitution principle. That is a > reference to an > object which supports interface D can be passed where a reference to an > object which supports interface B is expected if and only if B is a base > interface of D." I believe that is a better wording than in the original and captures the intent of the original proposal much better. So I am going to put this wording up for consideration in vote 4. > 2848: The wording is still too loose, since it doesn't describe what > forms of recursion with sequences are allowed. This can be inferred > from the grammar, but I would like the wording to be like this instead: > > "Although the IDL syntax allows the generation of recursive constructed > type > specifications, the only recursion permitted for constructed types with > the > exception of valuetypes is through the use of the sequence template > type. The component of a recursive sequence must identify a struct, > union or valuetype. A > valuetype is allowed to have a member of its own type either directly or > indirectly through a member of a constructed type." I like that wording better too and will be happy to put it up for vote. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jis@fpk.hp.com Message-ID: <38233141.2438D177@fpk.hp.com> Date: Fri, 05 Nov 1999 14:34:25 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <382226C6.D969C213@floorboard.com> <38232731.6C19A66C@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2UQ!!KQ~!!1_$e9hR0e9 Simon Nash wrote: > > Jonathan, > > Jonathan Biggar wrote: > > > > 1997: I agree with Juan that the wording isn't right, but I don't > agree > > with his counterproposal either. There is no such thing as a > reference > > to an interface, only references to an object. Try this instead: > > > > "Interfaces satisfy the Liskov subsitution principle. That is a > > reference to an > > object which supports interface D can be passed where a reference > to an > > object which supports interface B is expected if and only if B is > a base > > interface of D." > > > Sorry, but this is just plain wrong. Consider the following: > > interface B { > void bmethod(); > }; > interface D { > void dmethod(); > }; > interface C: B, D {}; > interface X { > void foo(in B myObj); > }; > > I can pass a C reference (which supports interface D) to method foo > even though > B is not a base interface of D. > > What exactly is the problem we are trying to fix by adding this > paragraph? > Are we talking about what can validly be passed at runtime, or about > substitutions > that can be validated by an IDL compiler, or by a programming > language compiler? Subsitution that can be validated by an IDL compiler I should think. Anyway, I will hold off any further vote on this issue until Jon and Simon, (and Michi, who penned the original resolution) resolve their differences among themselves and come up with a final wording. The problem that we are fixing is stating precisely what sort of subsititution is permitted in the"CORBA/OMA model". So 1997 will not be on vote 4. Lookout for it in a later vote. Thanks, Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jon@floorboard.com Message-ID: <38232D1F.829264A@floorboard.com> Date: Fri, 05 Nov 1999 11:16:47 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <382226C6.D969C213@floorboard.com> <38232731.6C19A66C@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]N@!!bT_d9%@*!!daMd9 Simon Nash wrote: > > Jonathan, > > Jonathan Biggar wrote: > > > > 1997: I agree with Juan that the wording isn't right, but I don't > agree > > with his counterproposal either. There is no such thing as a > reference > > to an interface, only references to an object. Try this instead: > > > > "Interfaces satisfy the Liskov subsitution principle. That is a > > reference to an > > object which supports interface D can be passed where a reference > to an > > object which supports interface B is expected if and only if B is > a base > > interface of D." > > > Sorry, but this is just plain wrong. Consider the following: > > interface B { > void bmethod(); > }; > interface D { > void dmethod(); > }; > interface C: B, D {}; > interface X { > void foo(in B myObj); > }; > > I can pass a C reference (which supports interface D) to method foo > even though > B is not a base interface of D. > > What exactly is the problem we are trying to fix by adding this > paragraph? > Are we talking about what can validly be passed at runtime, or about > substitutions > that can be validated by an IDL compiler, or by a programming > language compiler? If I wanted to be pendantic, I would rewrite the paragraph to say something like this: "subsitution is allowed if and only if there exists an interface D, which the actual object reference supports, which is derived from the formal interface type B" or some such. However, if you go back and reread my wording above, it says the same thing in laymans terms. In your example, a reference to an object that supports C also supports B, so the subsitution is legal. You happened to pick different names for your interfaces than I did, which makes your example different. Rewrite it like this: interface B { void bmethod(); }; interface C { void dmethod(); }; interface D: B, C {}; interface X { void foo(in B myObj); }; and your names match (semantically as well as lexically) those used in my paragraph. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Sender: jis@fpk.hp.com Message-ID: <382333BA.665A1E75@fpk.hp.com> Date: Fri, 05 Nov 1999 14:44:58 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash Cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <382226C6.D969C213@floorboard.com> <38232731.6C19A66C@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =kI!!*kXd9Zi/e91("e9 Simon Nash wrote: > > Jonathan, > > Jonathan Biggar wrote: > > > > 1997: I agree with Juan that the wording isn't right, but I don't > agree > > with his counterproposal either. There is no such thing as a > reference > > to an interface, only references to an object. Try this instead: > > > > "Interfaces satisfy the Liskov subsitution principle. That is a > > reference to an > > object which supports interface D can be passed where a reference > to an > > object which supports interface B is expected if and only if B is > a base > > interface of D." > > > Sorry, but this is just plain wrong. Consider the following: > > interface B { > void bmethod(); > }; > interface D { > void dmethod(); > }; > interface C: B, D {}; > interface X { > void foo(in B myObj); > }; I did a search for "Liskov Substitution" in Yahoo:-), and came up with the following ( with a little tweaking to align terminology with CORBA-isms): "If interface A is derived from interface B, then anytime a reference to an object which supports interface B is expected a reference to an object which support interface A can be passed." How's that? I think the porblem with the original statement from Michi was the "only if" part. Anyway, discuss and come up with agreed upon language, then we will vote on it. Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Posted-Date: Fri, 5 Nov 1999 17:48:40 +0100 (MET) Message-ID: <38230A76.6805B84D@tid.es> Date: Fri, 05 Nov 1999 17:48:54 +0100 From: "Juan J. Hierro" Organization: Telefonica I+D X-Mailer: Mozilla 4.05 [en] (WinNT; I) MIME-Version: 1.0 To: Jishnu Mukerji CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Core RTF 2k Vote 3 Announcement References: <381A0B26.E45E7741@fpk.hp.com> <382226C6.D969C213@floorboard.com> <3822F28D.9D7524D5@fpk.hp.com> Content-Type: multipart/mixed; boundary="------------AE95A40EF5108D80CF0A1CB5" X-UIDL: C>~e9k9Y!!Q=6!!ZN"!! Hello all, Jishnu Mukerji wrote: > > Jonathan Biggar wrote: > > > 1997: I agree with Juan that the wording isn't right, but I don't > agree > > with his counterproposal either. There is no such thing as a > reference > > to an interface, only references to an object. Try this instead: > > > > "Interfaces satisfy the Liskov subsitution principle. That is a > > reference to an > > object which supports interface D can be passed where a reference > to an > > object which supports interface B is expected if and only if B is > a base > > interface of D." > > I believe that is a better wording than in the original and captures > the intent > of the original proposal much better. So I am going to put this > wording up for > consideration in vote 4. > I like Jonathan proposal above. I would vote YES for its adoption whenever the vote takes place. > > 2848: The wording is still too loose, since it doesn't describe what > > forms of recursion with sequences are allowed. This can be inferred > > from the grammar, but I would like the wording to be like this instead: > > > > "Although the IDL syntax allows the generation of recursive constructed > > type > > specifications, the only recursion permitted for constructed types with > > the > > exception of valuetypes is through the use of the sequence template > > type. The component of a recursive sequence must identify a struct, > > union or valuetype. A > > valuetype is allowed to have a member of its own type either directly or > > indirectly through a member of a constructed type." > > I like that wording better too and will be happy to put it up for vote. > I also like it ! Cheers, -- Juanjo [] vcard1.vcf Reply-To: From: "Nick Sharman" To: "Simon Nash" , "Jonathan Biggar" Cc: "Jishnu Mukerji" , Subject: RE: Issue 1997 (was: Core RTF 2k Vote 3 Announcement) Date: Mon, 8 Nov 1999 10:38:52 -0000 Message-ID: <000e01bf29d5$72d7a050$5610a8c0@thumper.uk.peerlogic.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <38232731.6C19A66C@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: A%'!!nCTd9VaV!!&G/e9 Simon Nash wrote: > > Jonathan Biggar wrote: > > > > 1997: I agree with Juan that the wording isn't right, but I don't agree > > with his counterproposal either. There is no such thing as a reference > > to an interface, only references to an object. Try this instead: > > > > "Interfaces satisfy the Liskov subsitution principle. That is a > > reference to an > > object which supports interface D can be passed where a reference to an > > object which supports interface B is expected if and only if B is a base > > interface of D." > > > Sorry, but this is just plain wrong. Consider the following: > > interface B { > void bmethod(); > }; > interface D { > void dmethod(); > }; > interface C: B, D {}; > interface X { > void foo(in B myObj); > }; > > I can pass a C reference (which supports interface D) to method > foo even though > B is not a base interface of D. > Simon is right, of course; we've lost the phrase "most derived type" from the original proposal, which was: Interfaces satisfy the Liskov subsitution principle. That is a reference to an interface whose most derived type is D can be passed where a reference to an interface of type B is expected if and only if B is a base interface of D. Jon's re-re-wording: Jon Biggar wrote: > If I wanted to be pendantic, I would rewrite the paragraph to say > something like this: "subsitution is allowed if and only if there > exists an interface D, which the actual object reference supports, > which > is derived from the formal interface type B" or some such. gets nearer the mark. One of Simon's points is that "expected" is loosely defined. As I understand it, his implementation of X::foo() will try to use D::dmethod(), even though myObj is only declared as B. I _think_ Simon's point is that in some sense X::foo() expects to receive a C, but what happens if the client sends a reference to E, where: interface E: B, D {}; In fact, the C versus E issue doesn't really apply: we can code X::foo() as: // Java class XImpl extends XPOA { public void foo (B myObj) { D myD = DHelper.narrow (myObj); if (myD != null) { myD.dmethod(); } } } I.e. there's no mention of C. The client of X does however need to be aware of some IDL that includes the definition of C, or E, or any other single interface that derives from both B and D. The checking in the narrow() call is purely dynamic, presumably implemented via an "_is_a" request; there's no need for XImpl to be aware of any inheritance graph that links B and D. > What exactly is the problem we are trying to fix by adding this paragraph? > Are we talking about what can validly be passed at runtime, or > about substitutions > that can be validated by an IDL compiler, or by a programming > language compiler? Essentially, we are talking about runtime substitutability. At runtime, the only objects a client can pass to X::foo() are those that support B, not anthing that happens to implement bmethod(). Within the body of XImpl.foo(), we only get a non-nil reference back from the narrow when the object also supports D, and not when it just happens to implement dmethod(). However, that requirement on runtime substitutability also allows language mappings to support implementations of interface types that police the rule at programming-language compile time. For example, C++ and Java mappings allo references with m.d.t.B and C to be passed to X::foo(), but not reference with m.d.t. D or X. I don't think it says anything new about IDL compile time, since we are only talking about interfaces. For example if B derives from D, B can't redefine an operation of D, so we don't need to worry about contravariant or covariant substitution of parameters or results. Regards Nick Sender: jis@fpk.hp.com Message-ID: <38276F1C.1420B063@fpk.hp.com> Date: Mon, 08 Nov 1999 19:47:24 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 1997 again Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: m$a!!>9j!!iga!!Uj[!! Try this one. It covers both the "if" and the "only if" part (I think) explicitly in two sentences, instead of one. It will make Andrew unhappy because it includes the "only if" part thus excluding the case where one could allow substitution based on incidental alignment of operation names and parameter types.:-) "Interfaces satisfy the Liskov subsitution principle. If interface A is derived from interface B, then a reference to an object which supports interface A can be passed wherever a reference to an object which support interface B is expected. Additionally, if interface A is not derived from interface B, then a reference to an object that support interface A cannot be passed where a reference to an object that supports interface B is expected." Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Date: Tue, 9 Nov 1999 12:09:41 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jishnu Mukerji cc: orb_revision@omg.org Subject: Re: Issue 1997 again In-Reply-To: <38276F1C.1420B063@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: o+Sd9:!kd9kGpd9lA2e9 On Mon, 8 Nov 1999, Jishnu Mukerji wrote: > "Interfaces satisfy the Liskov subsitution principle. If interface A is derived > from interface B, then a reference to an object which supports interface A can > be passed wherever a reference to an object which support interface B is > expected. Additionally, if interface A is not derived from interface B, then a > reference to an object that support interface A cannot be passed where a > reference to an object that supports interface B is expected." Editorial comments: > If interface A is derived > from interface B, then a reference to an object which supports > interface A can ^^^^^ > be passed wherever a reference to an object which support*s* > interface B is ^^^^^ ^^^ > expected. Additionally, if interface A is not derived from > interface B, then a > reference to an object that support interface A cannot be passed > where a > reference to an object that supports interface B is expected." Both "which" occurences must be changed to "that" because what follows is a defining clause. There is also a missing "s". Now, not meaning to be obstinate, but what is wrong with the following? Interfaces satisfy the Liskov substitution principle: a reference R is compatible with interface type I if and only if the actual interface type of R is I or is derived from I. I'm not trying to add to the confusion here, but the above strikes me as simpler? 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: jis@fpk.hp.com Message-ID: <38278606.1289637E@fpk.hp.com> Date: Mon, 08 Nov 1999 21:25:10 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Michi Henning CC: orb_revision@omg.org Subject: Re: Issue 1997 again References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Gcfd902od9\CGe9W'9!! Michi Henning wrote: > > On Mon, 8 Nov 1999, Jishnu Mukerji wrote: > > > "Interfaces satisfy the Liskov subsitution principle. If interface > A is derived > > from interface B, then a reference to an object which supports > interface A can > > be passed wherever a reference to an object which support > interface B is > > expected. Additionally, if interface A is not derived from > interface B, then a > > reference to an object that support interface A cannot be passed > where a > > reference to an object that supports interface B is expected." > > Editorial comments: > > > If interface A is derived > > from interface B, then a reference to an object which supports > interface A can > ^^^^^ > > be passed wherever a reference to an object which support*s* > interface B is > ^^^^^ ^^^ > > expected. Additionally, if interface A is not derived from > interface B, then a > > reference to an object that support interface A cannot be passed > where a > > reference to an object that supports interface B is expected." > > Both "which" occurences must be changed to "that" because what > follows is > a defining clause. There is also a missing "s". > > Now, not meaning to be obstinate, but what is wrong with the > following? > > Interfaces satisfy the Liskov substitution principle: a > reference R > is compatible with interface type I if and only if the > actual > interface type of R is I or is derived from I. > > I'm not trying to add to the confusion here, but the above strikes > me as > simpler? I like that. Now lets see if Simon picks a hole in it or not. If he does not by Friday, then I will propose a new vote on 1997 using your latest.:-) Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Sender: jon@floorboard.com Message-ID: <38279688.F7117240@floorboard.com> Date: Mon, 08 Nov 1999 19:35:36 -0800 From: Jonathan Biggar X-Mailer: Mozilla 4.6 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 1997 again References: <38276F1C.1420B063@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: V>]d9B!a!!BdOd9Tia!! Jishnu Mukerji wrote: > > Try this one. It covers both the "if" and the "only if" part (I > think) > explicitly in two sentences, instead of one. It will make Andrew > unhappy because > it includes the "only if" part thus excluding the case where one > could allow > substitution based on incidental alignment of operation names and > parameter > types.:-) > > "Interfaces satisfy the Liskov subsitution principle. If interface A > is derived > from interface B, then a reference to an object which supports > interface A can > be passed wherever a reference to an object which support interface > B is > expected. Additionally, if interface A is not derived from > interface B, then a > reference to an object that support interface A cannot be passed > where a > reference to an object that supports interface B is expected." If someone wants to be pendantic, they could claim that it disallows multiple inheritence: interface B {}; interface C {}; interface A : B, C {}; You could claim that A is derived from C, which is not B and thus cannot be substituted for a B. I still think that my last proposal was quite clear. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Tue, 09 Nov 1999 09:39:05 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jishnu Mukerji CC: orb_revision@omg.org Subject: Re: Issue 1997 again References: <38276F1C.1420B063@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2UN!!UT1!!bjJe9%*&!! Jishnu, Jishnu Mukerji wrote: > > Try this one. It covers both the "if" and the "only if" part (I > think) > explicitly in two sentences, instead of one. It will make Andrew > unhappy because > it includes the "only if" part thus excluding the case where one > could allow > substitution based on incidental alignment of operation names and > parameter > types.:-) > I glad to hear that Andrew shares my concerns about the confusion > between runtime substitutability and declared type compatibility. If we are trying to > specify the latter (as you stated in an earlier response), why is the proposed > text always expressed in terms of the former? > "Interfaces satisfy the Liskov subsitution principle. If interface A is derived > from interface B, then a reference to an object which supports interface A can > be passed wherever a reference to an object which support interface B is > expected. Additionally, if interface A is not derived from interface B, then a > reference to an object that support interface A cannot be passed where a > reference to an object that supports interface B is expected." > The final sentence of the above is clearly incorrect, for the reason I gave in my last response to Jonathan: interface A { void amethod(); }; interface B { void bmethod(); }; interface C: A, B {}; interface X { void foo(in B myObj); }; I can pass a C reference (which supports interface A) to method foo which expects interface B even though A is not derived from B. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 09 Nov 1999 09:58:38 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Michi Henning CC: Jishnu Mukerji , orb_revision@omg.org Subject: Re: Issue 1997 again References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: $#:e9M[Yd9X~,e9aNn!! Michi, Michi Henning wrote: > > On Mon, 8 Nov 1999, Jishnu Mukerji wrote: > > > "Interfaces satisfy the Liskov subsitution principle. If interface > A is derived > > from interface B, then a reference to an object which supports > interface A can > > be passed wherever a reference to an object which support > interface B is > > expected. Additionally, if interface A is not derived from > interface B, then a > > reference to an object that support interface A cannot be passed > where a > > reference to an object that supports interface B is expected." > > Editorial comments: > > > If interface A is derived > > from interface B, then a reference to an object which supports > interface A can > ^^^^^ > > be passed wherever a reference to an object which support*s* > interface B is > ^^^^^ ^^^ > > expected. Additionally, if interface A is not derived from > interface B, then a > > reference to an object that support interface A cannot be passed > where a > > reference to an object that supports interface B is expected." > > Both "which" occurences must be changed to "that" because what > follows is > a defining clause. There is also a missing "s". > > Now, not meaning to be obstinate, but what is wrong with the > following? > > Interfaces satisfy the Liskov substitution principle: a > reference R > is compatible with interface type I if and only if the > actual > interface type of R is I or is derived from I. > > I'm not trying to add to the confusion here, but the above strikes > me as > simpler? > It is certainly simpler, but I am not sure about the term "actual > interface type". Is this the same as "most derived interface type"? If so, the latter > term should be used since it is already established CORBA terminology. However, I think the above has lost something in that it only specifies the relationship between the most derived type of the reference and the declared interface type. What about intervening interface types in the hierarchy? Here is my attempt to include these: "Interfaces satisfy the Liskov subsitution principle. If interface A is derived from interface B, then a reference to an object which supports interface A can always be used where an expected type of interface B is declared." It does not include the "only if" part, but I am not sure why this is needed. Perhaps someone can enlighten me on this point. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Paul Kyzivat To: "'jis@fpk.hp.com'" , "'orb_revision@omg.org'" Subject: RE: Issue 1997 again Date: Tue, 9 Nov 1999 09:42:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: cKQd90jj!!Sp2!!_\5!! > From: jis@fpk.hp.com [mailto:jis@fpk.hp.com] ... > Try this one... > > "Interfaces satisfy the Liskov subsitution principle. If > interface A is derived from interface B, then a reference > to an object which supports interface A can be passed wherever > a reference to an object which support interface B is > expected. Additionally, if interface A is not derived from > interface B, then a reference to an object that support interface > A cannot be passed where a reference to an object that supports > interface B is expected." The second part of this still has problems. The fact that A is not derived from B doesn't necessarily imply that an object that *supports* A cannot also support B. E.g. interface B{}; interface A{}; interface D : A,B {}; A reference to an object that supports D seems to conform to the rules of both the first and second clause. I think perhaps the problem is with statements of the form "a reference to an object that supports". One way to define this is in terms of is_a: "When a reference to an object which supports interface A is expected, a reference R may be used iff R.is_a(A)." This definition however has a couple of problems: - it isn't defined when R is null. - it doesn't support compile time checking. To deal with these problems we need a distinction between static types and dynamic types, for references. And CORBA currently has no such notion in the core. (It does exist in language bindings and possibly in UML.) One approach is to punt this to the language bindings and only deal with the dynamic issues. So we could say: "When an operation declaration in IDL specifies that (a part of) an argument is an interface of type A, the corresponding value in an invocation shall be a reference R where R is nil or R.is_a(A)." This doesn't require that the is_a be done; only that it is invalid to pass a reference for which the is_a, if done, would fail. The static typing issues are actually more interesting. But I don't currently see a way of addressing them in the core. I am especially interested in exactly how much static reasoning about the type lattice is valid. But perhaps that should be another issue.