Issue 565: Terminology consistency (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: What terminology should the core settle on? Interface inheritance with use of subtype/supertype? What about immediate and transitive versions of relationships? Resolution: resolved closed issue Revised Text: This issue is being addressed by the ORMSC in its revision of the OMA. When they complete the revision a new issue if necessary will be filed to bring the Core Chapters 1 and 2 in line with the new OMA. For now nothing should be done in this regard to the Core chapters pending the completion of the OMA revision Actions taken: May 20, 1997: received issue August 12, 1999: closed issue Discussion: End of Annotations:===== Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AF693740 Date: Tue, 20 May 1997 13:19:08 PDT Subject: terminology questions To: orb_revision@omg.org, ormsc@omg.org cc: Mike_Spreitzer.PARC@xerox.com I'm trying to make chapter 1 use terminology consistently within itself, with the rest of the Core; ideally we'll make the whole Core consistent with itself and the rest of the CORBA spec (um, to the degreee *that*'s consistent). So here are a couple questions about what terminology you think the Core should settle on. They concern the terms around interface inheritance. Do we use "subtype"/"supertype" (certainly not subclass/superclass), or "derived"/"base" interface, or something else? I think "derived"/"base interface. Now for some more subtle questions, concerning "immediate" versus "transitive" versions of the relationship. Ideally, we'll have terms for both. One term to use when X is listed among the interfaces from which Y inherits, and another term for the transitive closure of that relationship. Terms like "derived from", "ancestor of", "parent of", come to mind. Most are ambiguous, in that they could mean either the immediate or the transitive relationship. So I suggest we use compound terms that make this explicit, by saying "immediate" or "transitive". Thus: X is "immediately derived from" Y when X is listed among the interfaces from which Y inherits, and X is "transitively derived from" Y when either X is derived from Y or X is derived from some Z that itself is transitively derived from Y. Return-Path: Sender: jis@fpk.hp.com Date: Tue, 20 May 1997 17:58:38 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard New Jersey Labs To: Mike_Spreitzer.PARC@xerox.com Cc: orb_revision@omg.org, ormsc@omg.org Subject: Re: terminology questions References: <97May20.131936pdt."18098(7)"@alpha.xerox.com> Mike_Spreitzer.PARC@xerox.com wrote: > They concern the terms around interface inheritance. Do we use > "subtype"/"supertype" (certainly not subclass/superclass), or "derived"/"base" > interface, or something else? I think "derived"/"base interface. I agree with you. The term "type" is overloaded and means different things to different people. Besides interfaces deal only in "structural type" (structural referring to the structure of the intrface) and not any semantics behind the interface. So it is a term that is best avoided in this context. > Now for some > more subtle questions, concerning "immediate" versus "transitive" versions of > the relationship. Ideally, we'll have terms for both. One term to use when X > is listed among the interfaces from which Y inherits, and another term for the > transitive closure of that relationship. Terms like "derived from", "ancestor > of", "parent of", come to mind. Most are ambiguous, in that they could mean > either the immediate or the transitive relationship. So I suggest we use > compound terms that make this explicit, by saying "immediate" or "transitive". > Thus: X is "immediately derived from" Y when X is listed among the interfaces > from which Y inherits, and X is "transitively derived from" Y when either X is > derived from Y or X is derived from some Z that itself is transitively derived > from Y. I like that. And for "X is derived from some Z that itself is derived from Y" - "indirectly derived from"? So that "transitively derived from" == "immediately derived from" "or" "indirectly derived from" Jishnu. Return-Path: X-Sender: andrew@emerald.omg.org Date: Tue, 20 May 1997 19:16:09 -0400 To: Mike_Spreitzer.PARC@xerox.com From: Andrew Watson Subject: Re: terminology questions Cc: orb_revision@omg.org, ormsc@omg.org Mike, You wrote: > I'm trying to make chapter 1 use terminology consistently within itself, > with the rest of the Core; ideally we'll make the whole Core consistent > with itself and the rest of the CORBA spec And with Chapter 4 of the OMAG. > They concern the terms around interface inheritance. Do we use > "subtype"/"supertype" (certainly not subclass/superclass), or > "derived"/"base" interface, or something else? I think "derived"/"base > interface. Personally, I'd probably go for subtype/supertype; however, I do agree that subclass/superclass is incorrect. There's also the perennial question as to whether an interface that does not inherit from another is barred from being a subtype of it. My reading is that the adoption of IIOP 1.1 has defined method naming in such a way that interfaces can have a subtype/supertype relationship without inheritance. Chapter 1 should therefore make a clear distinction between inheritance and subtyping, and we'll need to have both derived/base and subtype/supertype terminology for these two different things. > Now for some > more subtle questions, concerning "immediate" versus "transitive" versions > of the relationship. Ideally, we'll have terms for both. One term to use > when X is listed among the interfaces from which Y inherits, and another > term for the transitive closure of that relationship. Terms like "derived > from", "ancestor of", "parent of", come to mind. Most are ambiguous, in > that they could mean either the immediate or the transitive relationship. > So I suggest we use compound terms that make this explicit, by saying > "immediate" or "transitive". I agree - the terms "immediate" and "transitive" capture this nicely. Cheers, Andrew Return-Path: Date: Thu, 22 May 97 14:22:24 EDT From: edbark@cme.nist.gov (Ed Barkmeyer) To: orb_revision@omg.org Subject: Re: terminology questions Cc: ormsc@omg.org Mike asks > > They concern the terms around interface inheritance. Do we use > > "subtype"/"supertype" (certainly not subclass/superclass), or > > "derived"/"base" interface, or something else? I think "derived"/"base > > interface. And Andrew responds: > Personally, I'd probably go for subtype/supertype; however, I do agree that > subclass/superclass is incorrect. I take Jishnu's point that "inheritance" in IDL is basically a lexical notion: interface A : B means interface A includes all the operations defined for interface B, and does not necessarily assume that B is a "type" (another loaded word). In my view, B is a "type" exactly when it is used to characterize objects by whether or not they support the attributes and operations defined in interface B. (This is the "intentional" definition of "type" and the one used in the OM.) Not all interfaces are used in this way. In fact, in a given context, B is only a "type" if it is USED as the "type" of an attribute, parameter or result. And A can only be a "subtype" when B is a "type". For this reason, I think Mike and Jishnu are right -- "derived/base" is a better terminology. Andrew himself supports this argument: > There's also the perennial question as to whether an interface that does > not inherit from another is barred from being a subtype of it. My reading > is that the adoption of IIOP 1.1 has defined method naming in such a way > that interfaces can have a subtype/supertype relationship without > inheritance. That is, "interface A is a subtype of interface B" exactly when all objects that support interface A necessarily support all attributes and operations of interface B (which is the IIOP concern). This is true if either: - A is stated to inherit from B, or - the definition of interface A contains (verbatim) all the attribute and operation signatures that are present in interface B. (Technically, the subtype notion requires that the semantics of the operations be identical as well.) So "subtype" depends on the "type" notion being ascribed to both A and B, whereas "inheritance" is one of two lexical means of expressing the lexical aspects of that notion. (There is further complexity in the IIOP spec for compatibility here that we don't want to get into.) > Chapter 1 should therefore make a clear distinction between > inheritance and subtyping, and we'll need to have both derived/base and > subtype/supertype terminology for these two different things. Exactly. -Ed Barkmeyer ------------------------------------------------------------------------ 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 Return-Path: Date: Thu, 22 May 1997 16:18:11 PDT Sender: Bill Janssen From: Bill Janssen To: orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer) Subject: Re: terminology questions CC: ormsc@omg.org References: <9705221822.AA01462@radio.cme.nist.gov> Excerpts from local.omg: 22-May-97 Re: terminology questions Ed Barkmeyer@cme.nist.go (2885) > That is, "interface A is a subtype of interface B" exactly when all objects > that support interface A necessarily support all attributes and operations > of interface B (which is the IIOP concern). This is true if either: > - A is stated to inherit from B, or > - the definition of interface A contains (verbatim) all the attribute > and operation signatures that are present in interface B. I believe that the second condition should be explicitly excluded from the CORBA spec. That is, CORBA should have exactly one notion of ``subtyping'', which should be inheritance. This does not mean that a system which is used to realize a CORBA application, such as C++, should not support additional definitions of subtyping, just that the CORBA model should not. I say this because I feel that it is maximally useful to consider that an interface creates a context which implicitly tags the operations which are defined inside it. Consider the following two interfaces: interface A { void op1 (); }; interface B { void op1 (); }; We should avoid saying, for CORBA, that A is a subtype of B, or that B is a subtype of A. Both A and B are services which export some operation op1, but the actual meaning of calling op1 is reserved to the service. That is, A::op1() and B::op1() should be distinguishable at the CORBA level (though an implementation may blur the distinction). It is foolish, and a marked weakness of CORBA in comparison to DCOM, that one cannot write interface C : A, B { void op2 (); }; We should modify the IDL rules to allow this. Bill Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Fri, 23 May 1997 10:11:50 +1000 (EST) From: Michi Henning To: Bill Janssen cc: orb_revision@omg.org, Ed Barkmeyer , ormsc@omg.org Subject: Re: terminology questions On Thu, 22 May 1997, Bill Janssen wrote: > Excerpts from local.omg: 22-May-97 Re: terminology questions Ed > Barkmeyer@cme.nist.go (2885) > > > That is, "interface A is a subtype of interface B" exactly when all objects > > that support interface A necessarily support all attributes and operations > > of interface B (which is the IIOP concern). This is true if either: > > - A is stated to inherit from B, or > > - the definition of interface A contains (verbatim) all the attribute > > and operation signatures that are present in interface B. > > I believe that the second condition should be explicitly excluded from > the CORBA spec. I agree - this is really the distinction between static and dynamic typing (similar to the difference between C++ and Smalltalk typing). Right now, CORBA is a statically typed model. I'm not sure that it is possible to patch dynamic typing in as an afterthought without destroying the internal conherency of the platform and existing object model. > It is foolish, and a marked weakness of CORBA in comparison to DCOM, > that one cannot write > > interface C : A, B { > void op2 (); > }; > > We should modify the IDL rules to allow this. The problem with this is really not at the object model level, but at the language mapping level. I believe that ambiguous multiple inheritance was excluded because it makes it harder to map into languages that don't have support for disambiguation. No problem if you are mapping to C++, but ugly if you are mapping to C, or another OO language without support for multiple inheritance and disambiguation. You end up to have to use name namgling, or equally ugly things. Besides, I don't think the multiple inheritance limitation is serious. Consider: Use of inheritance is not something one should do lightly or in the spur of a moment. Rather, using inheritance should be a carefully considered design decision, because it has far-reaching implications. If you accept that, I believe name clashes through multiple inheritance will be quite rare, because as a rule, I am in control of most of the things, if not all, I inherit from (one exception could be the CORBA-defined objects - however, you rarely need to inherit from them to use them). Where name clashes are unavoidable, ambiguous multiple inheritance can usually be re-mapped to encapsulation and delegation. This isn't quite as pretty or elegant, admittedly. However, I would not call it "a marked weakness". To me, it's more like a "minor restriction". 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: <9705221822.AA01462@radio.cme.nist.gov> <9705221822.AA01462@radio.cme.nist.gov> Date: Thu, 22 May 1997 20:25:11 -0400 To: Bill Janssen From: Andrew Watson Subject: Re: terminology questions Cc: orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer), ormsc@omg.org Bill, You wrote: > > That is, "interface A is a subtype of interface B" exactly when all > > objects that support interface A necessarily support all attributes and > > operations of interface B (which is the IIOP concern). This is true if > > either: > > - A is stated to inherit from B, or > > - the definition of interface A contains (verbatim) all the > > attribute and operation signatures that are present in interface > > B. > > I believe that the second condition should be explicitly excluded from > the CORBA spec. That is, CORBA should have exactly one notion of > ``subtyping'', which should be inheritance. And I believe subtyping and inheritance should be distinct. Let's both now replay our well-worn arguments for the benefit of the CC list ... > I say this because I feel that it is maximally useful to consider that > an interface creates a context which implicitly tags the operations > which are defined inside it. Consider the following two interfaces: > > interface A { > void op1 (); > }; > interface B { > void op1 (); > }; > > We should avoid saying, for CORBA, that A is a subtype of B, or that B > is a subtype of A. Both A and B are services which export some > operation op1, but the actual meaning of calling op1 is reserved to the > service. That is, A::op1() and B::op1() should be distinguishable at > the CORBA level (though an implementation may blur the distinction). The flaw with this approach is that the difference between interfaces A & B cannot be represented within CORBA's terms of reference. Storing and using semantic information (somethimes called "metadata") about services at run-time is important, and is positioned elsewhere in the OMA - for instance, in a trader, or perhaps in the forthcoming metaobject facility. Since the semantics of A and B must be stored elsewhere, legislating that A and B are never interchangable at the CORBA level is counter-productive, since it *prevents* the trader (or metaobject faciltity, or whatever) saying that A and B *are* interchangable, if this is in fact the case. Whether A & B have the same semantics or not is no business of the ORB. ORBs exist to mechanise the transport of data between client and server. Representing the semantic compatibility of client and server is far too important a task to be left to inheritance graphs. If it's structurally possible to move the data then the ORB *must* be able to do it. Hence A & B should be interchangable as far as the ORB is concerned. > It is foolish, and a marked weakness of CORBA in comparison to DCOM, > that one cannot write > > interface C : A, B { > void op2 (); > }; > > We should modify the IDL rules to allow this. It would be useful - provided of course the resulting interface contains exactly one operation called op1, and is completely interchangable with: interface D { void op1 (); void op2 (); } (which probably isn't what you had in mind, even after you've indented the braces the way you prefer :-). Cheers, Andrew Return-Path: Date: Thu, 22 May 1997 18:07:59 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Michi Henning Subject: Re: terminology questions CC: orb_revision@omg.org, Ed Barkmeyer , ormsc@omg.org References: Excerpts from direct: 22-May-97 Re: terminology questions Michi Henning@dstc.edu.a (2786*) > No problem if you are mapping to C++, > but ugly if you are mapping to C, or another OO language without > support for multiple inheritance and disambiguation. You end up to have > to use name namgling, or equally ugly things. C is hardly another OO language, but in general you're right. I suspect I've got the most actual experience with fitting an ORB into a language, and my experience is that either that the language's multiple inheritance model already supports explicit disambiguation (C++, Python, Common Lisp, Guile Scheme with YASOS) or it has a badly designed multiple inheritance object system (Java, C, Modula-3) and needs some help. Java, being both fashionable and broken, is the largest impediment to doing something useful here. Bill Return-Path: Date: Thu, 22 May 1997 18:10:42 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Andrew Watson Subject: Re: terminology questions CC: orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer), ormsc@omg.org References: <9705221822.AA01462@radio.cme.nist.gov> <9705221822.AA01462@radio.cme.nist.gov> Excerpts from direct: 22-May-97 Re: terminology questions Andrew Watson@omg.org (3125*) > The flaw with this approach is that the difference between interfaces A & B > cannot be represented within CORBA's terms of reference. Storing and using > semantic information (somethimes called "metadata") about services at > run-time is important, and is positioned elsewhere in the OMA - for > instance, in a trader, or perhaps in the forthcoming metaobject facility. > Since the semantics of A and B must be stored elsewhere, legislating that A > and B are never interchangable at the CORBA level is counter-productive, > since it *prevents* the trader (or metaobject faciltity, or whatever) > saying that A and B *are* interchangable, if this is in fact the case. > Whether A & B have the same semantics or not is no business of the ORB. > ORBs exist to mechanise the transport of data between client and server. > Representing the semantic compatibility of client and server is far too > important a task to be left to inheritance graphs. If it's structurally > possible to move the data then the ORB *must* be able to do it. > Hence A & B should be interchangable as far as the ORB is concerned. Unfortunately, this model is too weak to be useful. Bill Return-Path: Date: Fri, 23 May 1997 07:52:08 -0400 From: Richard Mark Soley To: michi@dstc.edu.au CC: janssen@parc.xerox.com, orb_revision, edbark@cme.nist.gov, ormsc Subject: terminology questions Reply-to: soley@omg.org Errors-to: soley_errors@omg.org Date: Fri, 23 May 1997 10:11:50 +1000 (EST) From: Michi Henning cc: orb_revision@omg.org, Ed Barkmeyer , ormsc@omg.org > We should modify the IDL rules to allow this. The problem with this is really not at the object model level, but at the language mapping level. I believe that ambiguous multiple inheritance was excluded because it makes it harder to map into languages that don't have support for disambiguation. No problem if you are mapping to C++, but ugly if you are mapping to C, or another OO language without support for multiple inheritance and disambiguation. You end up to have to use name namgling, or equally ugly things. Yes, I was there, that was why (plus a marked inability by at least one delegate to the RTF to differentiate between interface and implementation). However, Michi, we already *DO* some relatively ugly name mangling in the C mapping, you have to because it doesn't have inheritance of any kind. Why leave this broken for other languages mappings? -- Richard Return-Path: X-Authentication-Warning: foxtail.dstc.edu.au: michi owned process doing -bs Date: Fri, 23 May 1997 23:14:41 +1000 (EST) From: Michi Henning To: Richard Mark Soley cc: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org Subject: Re: terminology questions On Fri, 23 May 1997, Richard Mark Soley wrote: > > The problem with this is really not at the object model level, but at > the language mapping level. I believe that ambiguous multiple inheritance > was excluded because it makes it harder to map into languages that don't > have support for disambiguation. No problem if you are mapping to C++, > but ugly if you are mapping to C, or another OO language without > support for multiple inheritance and disambiguation. You end up to have > to use name namgling, or equally ugly things. > > Yes, I was there, that was why (plus a marked inability by at least one > delegate to the RTF to differentiate between interface and implementation). > > However, Michi, we already *DO* some relatively ugly name mangling in the C > mapping, you have to because it doesn't have inheritance of any kind. Why > leave this broken for other languages mappings? Well, that's a good question. That approach simply hadn't occured to me... To paraphrase you (no, I'm not sarcastic): The mapping for some languages is so ugly already, it doesn't matter if the ugliness gets a little worse. This coincidentally reflects my feelings about the C mapping. It's so cumbersome that I'd rather not use it at all (and therefore I don't care if it gets even uglier than it is already). This is not a criticism on part the of the C mapping designers. Of course the mapping is ugly, because a non-OO language doesn't lend itself to doing OO things. The ugliness is inherent in the mapping problem, not in the specific mapping design. Also to paraphrase: For those languages that permit an elegant mapping, we'll have an elegant mapping. For those languages that don't, we'll have a less elegant mapping. Limitations of target languages shouldn't limit the IDL feature set, because otherwise we are forever restricted to the least common denominator. I can sort of agree with that philosophy. However, it worries me that we could end up in a position where we'd have to admit that you might as well forget about some target languages, because the mapping is so terrible for certain IDL constructs that you might as well not bother... I think some middle ground is probably best. Why not look at the contentious points like ambiguous multiple inheritance and overloading and draft a mapping for languages where it isn't obvious how to make the feature fit? Write some example code using the draft mapping to see what it looks like. Then stand back and see whether you are revolted enough to throw up and give it a miss, or whether you can live with it. If you can live with it, the feature goes in. If you are too revolted, the feature doesn't make it. I'm quit serious about this. I don't think we can afford to do things that would, for example, make the C mapping unusable. Even though *I* don't like it, that doesn't mean it isn't necessary or that other people don't use it. If we end up in a position where we upset the existing user base, we'll lose the plot. And I suspect the C mapping will be with us for quite some time yet... 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, 23 May 1997 07:45:27 -0400 From: Richard Mark Soley To: janssen@parc.xerox.com CC: orb_revision, edbark@cme.nist.gov, ormsc Subject: name collision [was: terminology questions] Reply-to: soley@omg.org Errors-to: soley_errors@omg.org Date: Thu, 22 May 1997 16:18:11 PDT From: Bill Janssen It is foolish, and a marked weakness of CORBA in comparison to DCOM, that one cannot write interface C : A, B { void op2 (); }; We should modify the IDL rules to allow this. Damn right. This has been stuck in my craw since the CORBA 1.1 RTF in early 1991. It was proposed by a small cast of characters in a dirty hotel meeting room at Logan Airport six years ago, and accepted by the membership, and it should be FIXED. Before you flame your response everybody: keep in mind the difference between the SPECIFICATION and the IMPLEMENTATION. Yes we'd have to define how you reference C's two op1's in the mappings and the DII, but Bill's example is a splendid one, and enough motivation to fix this BUG. -- Richard Return-Path: X-Sender: genillou@dimail.epfl.ch References: <9705221822.AA01462@radio.cme.nist.gov> <9705221822.AA01462@radio.cme.nist.gov> Date: Fri, 23 May 1997 16:18:51 +0200 To: Bill Janssen , orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer) From: Guy Genilloud Subject: Re: terminology questions Cc: ormsc@omg.org At 4:18 PM -0700 5/22/97, Bill Janssen wrote: > >Excerpts from local.omg: 22-May-97 Re: terminology questions Ed >Barkmeyer@cme.nist.go (2885) > >> That is, "interface A is a subtype of interface B" exactly when all objects >> that support interface A necessarily support all attributes and operations >> of interface B (which is the IIOP concern). This is true if either: >> - A is stated to inherit from B, or >> - the definition of interface A contains (verbatim) all the attribute >> and operation signatures that are present in interface B. > >I believe that the second condition should be explicitly excluded from >the CORBA spec. That is, CORBA should have exactly one notion of >``subtyping'', which should be inheritance. This does not mean that a >system which is used to realize a CORBA application, such as C++, should >not support additional definitions of subtyping, just that the CORBA >model should not. Bill, you seem to ignore that there has already been a huge exchange of email on this very topic. A working group (namely Andrew Watson all by himself ?) was set up and worked on a green paper on the topic... Changing the CORBA spec on this point is not possible without a formal process (maybe a RFP, but I am not sure). And many (most?, all?) type theoreticians will tell you that derivation and subtyping are two different things... (not to mention ODP). Regards, Guy -------------------------------------------------------------------- Dr. Guy Genilloud Computer Engineering Department 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: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AF9F3740 Date: Fri, 23 May 1997 08:36:47 PDT Subject: Re: terminology questions To: michi@dstc.edu.au cc: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org > > It is foolish, and a marked weakness of CORBA in comparison to DCOM, > > that one cannot write > > > > interface C : A, B { > > void op2 (); > > }; > > > > We should modify the IDL rules to allow this. > > The problem with this is really not at the object model level, but at > the language mapping level. Actually, there may be some interaction with the object model here. The second paragraph of 1.2.6 "Operations" says ``An operation is identified by an operation identifier. An operation is not a value.'' Of course, there's no definition of the technical term "operation identifier". But there is a suggestive use of exactly the term "identifier" is the schema given just a little later on for an operation signature. So this suggests that an "operation identifier" is a simple identifier, of the sort that appears in the operation name position in the IDL for an operation's signature. Which would, of course, make the sort of inheritance that Janssen and Soley are enthusing about problematic. I too would like to see this sort of inheritance allowed. But my job right now is to write down a clear expression of the current design. So is it agreed that the inheritance that Janssen and Soley are enthusing about is not allowed by the current design? And if so, who can change it, when? Can the ORB RTF change it for 2.1? Return-Path: X-Sender: curtis@192.67.184.65 Date: Fri, 23 May 1997 12:31:14 -0400 To: edbark@cme.nist.gov (Ed Barkmeyer), orb_revision@omg.org From: David Curtis Subject: Re: terminology questions Cc: ormsc@omg.org Hi all, My two piasters: At 02:22 PM 5/22/97 EDT, Ed Barkmeyer wrote: >Mike asks >> > They concern the terms around interface inheritance. Do we use >> > "subtype"/"supertype" (certainly not subclass/superclass), or >> > "derived"/"base" interface, or something else? I think "derived"/"base >> > interface. > >And Andrew responds: >> Personally, I'd probably go for subtype/supertype; however, I do agree that >> subclass/superclass is incorrect. > >I take Jishnu's point that "inheritance" in IDL is basically a lexical >notion: > interface A : B >means interface A includes all the operations defined for interface B, >and does not necessarily assume that B is a "type" (another loaded word). >In my view, B is a "type" exactly when it is used to characterize objects >by whether or not they support the attributes and operations defined in >interface B. (This is the "intentional" definition of "type" and the one >used in the OM.) Not all interfaces are used in this way. In fact, in a >given context, B is only a "type" if it is USED as the "type" of an >attribute, parameter or result. And A can only be a "subtype" when B >is a "type". For this reason, I think Mike and Jishnu are right -- >"derived/base" is a better terminology. Sorry, but I don't have the slightest idea what you're getting at here... > >Andrew himself supports this argument: >> There's also the perennial question as to whether an interface that does >> not inherit from another is barred from being a subtype of it. My reading >> is that the adoption of IIOP 1.1 has defined method naming in such a way >> that interfaces can have a subtype/supertype relationship without >> inheritance. > >That is, "interface A is a subtype of interface B" exactly when all objects >that support interface A necessarily support all attributes and operations >of interface B (which is the IIOP concern). This is true if either: > - A is stated to inherit from B, or > - the definition of interface A contains (verbatim) all the attribute > and operation signatures that are present in interface B. >(Technically, the subtype notion requires that the semantics of the >operations be identical as well.) So "subtype" depends on the "type" >notion being ascribed to both A and B, whereas "inheritance" is one of two >lexical means of expressing the lexical aspects of that notion. >(There is further complexity in the IIOP spec for compatibility here that >we don't want to get into.) I don't entirely agree, with both the statement, and with the implication that this is what Andrew meant. I think what he's referring to (at the risk of putting uncouth American words in Andrew's mouth) is a side effect of a mechanical artifact in GIOP, that being the absence of information in a request describing the client's perception of the interface type it is using. A GIOP request contains no explicit information that tells the server environment/implementation object what the "type" (in any sense of the word) of the reference used to originate the request, or moreover, what "type" the client *thought* it was when it made the request. All you have is the unqualified name of the operation in a character string. The mechanical result of this is that the target object will (most likely) have whatever operation (if any) it supports with the same name invoked on it. God help you it that's not what you want to happen. Or worse yet, all the various dieties of the major religions help you if the operation signatures are different, but they aren't different enough to cause a marshalling error. You end up with an invocation that appears to be successful at both ends, but produces totally bogus results (and possibly bogus side effects) because it interpreted a float as a long, or something like that. This has interesting implications for type compatibility and substitutability in CORBA, but it's probably a bit of a stretch to assume that it's intended to reflect some deep theoretical notion of typing in CORBA. Neither I nor any of the other UNO authors (if my memory serves) were thinking that hard at the time (as Bill has so frequently pointed out ;-) > >> Chapter 1 should therefore make a clear distinction between >> inheritance and subtyping, and we'll need to have both derived/base and >> subtype/supertype terminology for these two different things. > >Exactly. I guess... The whole issue still seems muddy to me. David Curtis Director, Platform Technology Object Management Group Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFA13740 Date: Fri, 23 May 1997 09:58:59 PDT Subject: Re: terminology questions To: edbark@cme.nist.gov cc: orb_revision@omg.org, ormsc@omg.org You wrote: I take Jishnu's point that "inheritance" in IDL is basically a lexical notion: interface A : B means interface A includes all the operations defined for interface B, and does not necessarily assume that B is a "type" (another loaded word). In my view, B is a "type" exactly when it is used to characterize objects by whether or not they support the attributes and operations defined in interface B. (This is the "intentional" definition of "type" and the one used in the OM.) Not all interfaces are used in this way. In fact, in a given context, B is only a "type" if it is USED as the "type" of an attribute, parameter or result. And A can only be a "subtype" when B is a "type"... This raises an even more fundamental question. Let me warm up to it by saying that it's clear to me that there are multiple "aspects" to an interface: an interface can be used both as an object type, and as a linguistic construct (not unlike a name scope) to group together related declarations of various categories of things. I don't think it's useful to say an interface "is" a type only "where" it's used as a type, or even an interface "is" a type only *if* it's used *somewhere* as a type. Rather, let's say an interface always has a type aspect (even an interface that has no operations can be used as an object type), and always has other liguistic aspects. So here's the question: do the linguistic aspects of the "interface" concept belong in Chapter 1, or should they be entirely relegated to Chapter 3 because they only concern IDL? If you take the latter position, it seems to me that all that remains in chapter 1 is the type aspect. Which suggests we shouldn't talk (in Ch 1) about interfaces at all, only object types. Return-Path: X-Sender: genillou@dimail.epfl.ch References: Date: Fri, 23 May 1997 19:00:34 +0200 To: Mike_Spreitzer.PARC@xerox.com From: Guy Genilloud Subject: Re: terminology questions Cc: orb_revision@omg.org, ormsc@omg.org > >``An operation is identified by an operation identifier. An operation is not a >value.'' > >Of course, there's no definition of the technical term "operation identifier". >But there is a suggestive use of exactly the term "identifier" is the schema >given just a little later on for an operation signature. So this suggests >that >an "operation identifier" is a simple identifier, of the sort that appears in >the operation name position in the IDL for an operation's signature. Which >would, of course, make the sort of inheritance that Janssen and Soley are >enthusing about problematic. I too would like to see this sort of inheritance >allowed. But my job right now is to write down a clear expression of the >current design. So is it agreed that the inheritance that Janssen and Soley >are enthusing about is not allowed by the current design? And if so, who can >change it, when? Can the ORB RTF change it for 2.1? Mike, The identifier is just the operation name in CORBA. This means that there can be only one operation with a given name in a CORBA interface. Regarding inheritance in IDL, there is a "diamond rule" somewhere which says that an operation must be specified only once (i.e., it can be derived from two parents, but provided these parents have a common ancestor when that operation is defined). Regarding subtyping, all commercial implementations seem to do what Andrew Watson said they do -- they do not check inheritance for deciding about subtyping. Now, what a RTF can do or cannot do is beyond me. My guess is that changing the subtyping rules is beyond its scope. Relaxing IDL inheritance might be a possibility (just guessing). Regards, Guy -------------------------------------------------------------------- Dr. Guy Genilloud Computer Engineering Department 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: Fri, 23 May 1997 10:16:15 PDT Sender: Bill Janssen From: Bill Janssen To: Richard Mark Soley , Michi Henning Subject: Re: terminology questions CC: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org References: Excerpts from direct: 23-May-97 Re: terminology questions Michi Henning@dstc.edu.a (3350*) > However, it worries me that > we could end up in a position where we'd have to admit that you might > as well forget about some target languages, because the mapping is > so terrible for certain IDL constructs that you might as well not bother... That's right, but that's life. We, for example, finally gave up on Fortran-77 (after considerable effort) because the language and the paradigm were such a terrible fit. Fortran-90 seems possible, though. Bill Return-Path: From: Joe_Sventek@HP-PaloAlto-notesgw1.om.hp.com X-Openmail-Hops: 1 Date: Fri, 23 May 97 10:24:12 -0700 Subject: Re: name collision [was: terminology questions] To: soley@omg.org Cc: Orb_Revision@omg.org Item Subject: Lotus Notes Message Text Richard Soley wrote: > Date: Thu, 22 May 1997 16:18:11 PDT > From: Bill Janssen > > It is foolish, and a marked weakness of CORBA in comparison to DCOM, > that one cannot write > > interface C : A, B { > void op2 (); > }; > > We should modify the IDL rules to allow this. > >Damn right. This has been stuck in my craw since the CORBA 1.1 RTF in early >1991. It was proposed by a small cast of characters in a dirty hotel meeting >room at Logan Airport six years ago, and accepted by the membership, and it >should be FIXED. > >Before you flame your response everybody: keep in mind the difference between >the SPECIFICATION and the IMPLEMENTATION. Yes we'd have to define how you >reference C's two op1's in the mappings and the DII, but Bill's example is a >splendid one, and enough motivation to fix this BUG. Lest everyone think that this was the consensus of the small cast of characters in the dirty hotel meeting, I'd like to play historian, once again. When I wrote the initial specification for IDL during the ORB merge process, it permitted just what Bill suggests, together with an exact specification of the mapping to C. This naming overload capability was rejected by two of the participating companies, since the DII which was so crucial to their products needed to be able to disambiguate operation names at the simple name level. Attempts to have the operation name parameter to the DII be a fully-qualified name ("A::op1", for example) were similarly refuted. Since the goal of the 90-day ORB merge process was to achieve an agreed-upon ORB specification amongst the 5 companies, I had to remove this essential capability. Joe Sventek Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFA33740 Date: Fri, 23 May 1997 10:18:45 PDT Subject: Re: terminology questions To: michi@dstc.edu.au cc: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org You wrote: [[ Consider: Use of inheritance is not something one should do lightly or in the spur of a moment. Rather, using inheritance should be a carefully considered design decision, because it has far-reaching implications. If you accept that, I believe name clashes through multiple inheritance will be quite rare, because as a rule, I am in control of most of the things, if not all, I inherit from... ]] I just don't buy this. I often build on top of the work of others, and in a way that requires interoperation with other work constructed on top of the same lower-level interfaces. I am often required to work with interfaces designed by others. Yes, these are carefully considered design decisions. It seems to me that it's strongly desirable to enable me to construct an interface C from any two interfaces A and B designed earlier and independently with absolutely no expectation of their being common ancestors of anything. Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFA43740 Date: Fri, 23 May 1997 10:21:12 PDT Subject: Re: terminology questions To: michi@dstc.edu.au cc: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org You wrote: [[ On Thu, 22 May 1997, Bill Janssen wrote: > Excerpts from local.omg: 22-May-97 Re: terminology questions Ed > Barkmeyer@cme.nist.go (2885) > > > That is, "interface A is a subtype of interface B" exactly when all objects > > that support interface A necessarily support all attributes and operations > > of interface B (which is the IIOP concern). This is true if either: > > - A is stated to inherit from B, or > > - the definition of interface A contains (verbatim) all the attribute > > and operation signatures that are present in interface B. > > I believe that the second condition should be explicitly excluded from > the CORBA spec. I agree - this is really the distinction between static and dynamic typing (similar to the difference between C++ and Smalltalk typing)... ]] I disagree: this has nothing whatsoever to do with the difference between static and dynamic typing. Andrew's desired subtyping relationship is stated as a question about static types (and thus can be answered statically). Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFA53740 Date: Fri, 23 May 1997 10:30:13 PDT Subject: Re: terminology questions To: andrew@omg.org cc: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org You wrote: [[ Bill, You wrote: >... > interface A { > void op1 (); > }; > interface B { > void op1 (); > }; > > ... The flaw with this approach is that the difference between interfaces A & B cannot be represented within CORBA's terms of reference. Storing and using semantic information (somethimes called "metadata") about services at run-time is important, and is positioned elsewhere in the OMA - for instance, in a trader, or perhaps in the forthcoming metaobject facility. Since the semantics of A and B must be stored elsewhere, legislating that A and B are never interchangable at the CORBA level is counter-productive, since it *prevents* the trader (or metaobject faciltity, or whatever) saying that A and B *are* interchangable, if this is in fact the case. Whether A & B have the same semantics or not is no business of the ORB. ORBs exist to mechanise the transport of data between client and server. Representing the semantic compatibility of client and server is far too important a task to be left to inheritance graphs. If it's structurally possible to move the data then the ORB *must* be able to do it. Hence A & B should be interchangable as far as the ORB is concerned. ]] It seems clear to me that there is a difference between *identifying* semantics and *representing* them. And the former can be done without attempting the latter. Clearly IDL is not up to the task of *representing* semantics. However, it would probably be a positively good thing if there were a way of using identifiers in IDL to *identify* semantics. For one thing, this would enable the *representations* of semantics stored elsewhere to be unambiguously linked to the IDL they're referring to. Consider the problem of a semantics repository that wants to say that A::op1 has one semantics, and B::op1 has certain other semantics. If the "A" and "B" parts of those identifiers "cannot be represented within CORBA's terms of reference", the repository is hosed. Return-Path: Date: Fri, 23 May 1997 10:54:45 PDT Sender: Bill Janssen From: Bill Janssen To: ormsc@omg.org Subject: Re: terminology questions CC: orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer) References: <9705221822.AA01462@radio.cme.nist.gov> <9705221822.AA01462@radio.cme.nist.gov> Excerpts from local.omg: 22-May-97 Re: terminology questions Bill Janssen@parc.xerox. (1257) > Excerpts from direct: 22-May-97 Re: terminology questions Andrew > Watson@omg.org (3125*) > > Hence A & B should be interchangable as far as the ORB is concerned. > Unfortunately, this model is too weak to be useful. Perhaps I should explain myself. Andrew's position is certainly one of several that could be adopted, and perhaps natural for the appointed guardian of the status quo. However, it seems to have no redeeming advantages, and suffers from several noticable disadvantages. I see no reason to continue using a broken model just because we started with one. Consider: 1) If the interface in which an operation is defined is pointless, why bother with interfaces at all? Why not just allow operations to appear naked? One of the reasons is that interfaces form a scope which allows operations to be defined with a two-part name, one part being the interface scope, and the other part being the explicit operation name. That scope is both thus syntactically and semantically meaningful. Otherwise we'd be seeing IDL like interface A { void com_xerox_parc_ilu_op1(); }; This maps badly to most object-oriented languages, in which the scope in which an operation is defined is also significant. Consider what the Java mapping for this would be. 2) We badly need to allow arbitrary multiple inheritance, and thus be able to distinguish between two different "foo" methods defined in two different base classes. The fact that CORBA provides for and uses multiple inheritance is a advantage over DCOM in wide-area typing, which is a significant factor in Internet computing. However, this advantage is more than completely offset by CORBA's not allowing arbitrary aggregation of interfaces, as DCOM does. If an object does in fact export N different (but not incompatible) interfaces, it seems silly to break everything simply because of the fact that two operations in two of those interfaces happen to have the same name but different signatures or semantics. In fact, it makes it very difficult to honestly recommend CORBA for enterprise-wide information systems. Most of this unpleasantness could be resolved without major changes to the CORBA system by declaring that the ``real'' identifier for an operation consists of two parts: the CORBA repository id of the interface in which its syntax is defined, and the short identifier used in that definition. Bill Return-Path: Date: Fri, 23 May 97 15:01:22 EDT From: edbark@cme.nist.gov (Ed Barkmeyer) To: Mike_Spreitzer.PARC@xerox.com Subject: Re: terminology questions Cc: orb_revision@omg.org, ormsc@omg.org > I often build on top of the work of others, and in a > way that requires interoperation with other work constructed on top of the same > lower-level interfaces. I am often required to work with interfaces designed > by others. Yes, these are carefully considered design decisions. It seems to > me that it's strongly desirable to enable me to construct an interface C from > any two interfaces A and B designed earlier and independently with absolutely > no expectation of their being common ancestors of anything. Hear! Hear! Where I come from, this is called "software reuse". And it is nice to know that SOMEBODY does it now and then. You all might be amused to know that a very similar debate is going on this week in the email exploder for ISO TC184/SC4/WG11, where the issue is mapping the modelling language Express to Java. Express has the DCOM/C++ feature to which Bill alluded (although Express only has attributes at the moment), and the Java-ites want it removed or at least "deprecated" (i.e. the ISO group should say: don't use it). Interestingly, this discussion did not arise in the SDAI/IDL mapping group (also in WG11), who have nearly completed work (SDAI is the data manipulation API for Express). Perhaps they had the multiple-wart problem. I have copied selected elements of this discussion, including this comment from Mike, to them. (Given the tendency of this group to Reply-all, I decided not to cc: wg11@cme.nist.gov -- I don't need 3 copies of everything.) -Ed Return-Path: X-Sender: andrew@emerald.omg.org References: <9705221822.AA01462@radio.cme.nist.gov> <9705221822.AA01462@radio.cme.nist.gov> Date: Fri, 23 May 1997 14:50:44 -0400 To: Bill Janssen From: Andrew Watson Subject: Re: terminology questions Cc: ormsc@omg.org, orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer) Bill, You wrote: > Perhaps I should explain myself. Andrew's position is certainly one of > several that could be adopted, and perhaps natural for the appointed > guardian of the status quo. I've also heard it called dangerously radical. I suppose it all depends where you're starting from. > However, it seems to have no redeeming > advantages, and suffers from several noticable disadvantages. ... which is just how I view your position, of course. All nicely symmetrical. > Most of this unpleasantness could be resolved without major changes to > the CORBA system by declaring that the ``real'' identifier for an > operation consists of two parts: the CORBA repository id of the > interface in which its syntax is defined, and the short identifier used > in that definition. Thus for a group of objects bearing structurally-identical interfaces to be used interchangably, they would all have to refer to the same interface definition in the same interface repository. This works locally, but is too onerous a constraint for global systems. Well, we've both concisely summarised our respective arguments, and as usual neither of us looks likely to convince the other. Plus ca change. Cheers, Andrew Return-Path: Date: Fri, 23 May 1997 12:38:59 PDT Sender: Bill Janssen From: Bill Janssen To: Bill Janssen , Andrew Watson Subject: Re: terminology questions CC: ormsc@omg.org, orb_revision@omg.org, edbark@cme.nist.gov (Ed Barkmeyer) References: <9705221822.AA01462@radio.cme.nist.gov> <9705221822.AA01462@radio.cme.nist.gov> Excerpts from direct: 23-May-97 Re: terminology questions Andrew Watson@omg.org (1313*) > Thus for a group of objects bearing structurally-identical interfaces to be > used interchangably, they would all have to refer to the same interface > definition in the same interface repository. This works locally, but is too > onerous a constraint for global systems. No, not quite; they would all have to refer to interface defintions with the same repository ID, which is quite a different thing. Bill Return-Path: Date: Fri, 23 May 1997 15:34:22 -0400 From: Richard Mark Soley To: michi@dstc.edu.au CC: janssen@parc.xerox.com, orb_revision, edbark@cme.nist.gov, ormsc Subject: terminology questions Reply-to: soley@omg.org Errors-to: soley_errors@omg.org Date: Fri, 23 May 1997 23:14:41 +1000 (EST) From: Michi Henning cc: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org To paraphrase you (no, I'm not sarcastic): The mapping for some languages is so ugly already, it doesn't matter if the ugliness gets a little worse. This coincidentally reflects my feelings about the C mapping. It's so cumbersome that I'd rather not use it at all (and therefore I don't care if it gets even uglier than it is already). Interesting point. However, I'm not implying that it needs to get uglier than it already is (for C) *for that which it already supports*. Just that the mapping to support this particular issue needn't be any worse than what is currently done. I am *NOT* saying that any arbitrarily ugly mapping is good enough -- for example, as you've pointed out on comp.object.corba lately supporting IDL overloading (as opposed to overriding) would be hell in some mappings, notably IDL. This particular issue, however (supporting general multiple inheritance) introduces a bug in the overall object model because of syntactic problems in one or mappings. Seems like throwing the baby out with the bathwater. This is not a criticism on part the of the C mapping designers. Of course the mapping is ugly, because a non-OO language doesn't lend itself to doing OO things. The ugliness is inherent in the mapping problem, not in the specific mapping design. Agreed. And with apologies to Joe Sventek if slight was taken (but the hotel room *was* dirty :-). Also to paraphrase: For those languages that permit an elegant mapping, we'll have an elegant mapping. For those languages that don't, we'll have a less elegant mapping. Limitations of target languages shouldn't limit the IDL feature set, because otherwise we are forever restricted to the least common denominator. Nope. (That's what I like about engineers & lawyers, they'll take any statement to logical extremes :-). See above: I think it reasonable to exclude overloading in IDL because of mapping problems, despite the attendant lessening of the object model; I think it atrocious, however, to preclude quite straightforward multiple inheritance (therefore inducing likely unexpected errors at compile-time) because of a mapping change that will not break any existing code! I think some middle ground is probably best. Me too. But apparently there are several middle grounds :-) If we end up in a position where we upset the existing user base, we'll lose the plot. And I suspect the C mapping will be with us for quite some time yet... I agree.... -- Richard Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFA83740 Date: Fri, 23 May 1997 12:54:19 PDT Subject: The inheritance debate [was Re: terminology questions] To: ormsc@omg.org, orb_revision@omg.org cc: Mike_Spreitzer.PARC@xerox.com This is in regards to the debate between Janssen and Watson on inheritance and/or subtyping. The first question for me, with my Ch1 revision hat on, is: what is the current design? It now seems clear to me that the current design has neither what Bill wants nor what Andrew wants. The fact that the GIOP uses only the simple operation names, and the fact the the current language in Ch1 vaguely suggests that operation identifiers are simple names, tells me that what Bill wants is not there now. The fact that 1.2.5 "Interfaces" currently says "Interface inheritance provides the composition mechanism for permitting an object to support multiple interfaces" (this is awkward, IMHO, but somewhat answers the question at hand), and the fact that Andrew recognizes he's promoting a debatable position, tells me that what Andrew wants is not in the current design. Agreed? The next question is: what can be changed by the ORB RTF for 2.1? It seems clear to me that neither what Bill wants nor what Andrew wants is a small enough change to do for 2.1. Agreed? The remaining questions are about what can and should be changed later. I'll think about that later. Right now, it seems to me that what Bill wants and what Andrew wants are mutually exclusive, but *I* want them both. So I'll have to think on this... Mike Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFAE3740 Date: Fri, 23 May 1997 14:37:44 PDT Subject: Re: terminology questions To: soley@omg.org cc: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org, ormsc@omg.org > This particular issue, however (supporting general multiple inheritance) > introduces a bug in the overall object model because of syntactic problems in > one or mappings. Seems like throwing the baby out with the bathwater. It seems to me it's not just a matter of problems in a few mappings. It involves a fundamental question about the object model, and resolves that question in a way that precludes the more liberal subtyping relationships that Andrew has been arguing for. Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFAF3740 Date: Fri, 23 May 1997 14:47:14 PDT Subject: Nothing but object types To: ormsc@omg.org, orb_revision@omg.org cc: Mike_Spreitzer.PARC@xerox.com Shall I infer from the lack of response to my message below that nobody has an opinion on whether Ch1 should exclude any mention of interfaces, leaving only object types? ---------------------------------------------------------------- Subject: The inheritance debate [was Re: terminology questions] Message-ID: <97May23.125447pdt."16591(10)"@alpha.xerox.com> To: ormsc@omg:org, orb_revision@omg:org Cc: Mike Spreitzer From: Mike Spreitzer:PARC:Xerox Received: from emerald ([192.67.184.65]) by alpha.xerox.com with SMTP id <17568(12)>; Fri, 23 May 1997 13:56:42 PDT Received: from alpha.xerox.com by emerald (SMI-8.6/SMI-SVR4) id PAA19515; Fri, 23 May 1997 15:57:28 -0400 Received: from Gabriel.Parc.Xerox.xns by alpha.xerox.com via XNS id <16591(10)>; Fri, 23 May 1997 12:54:47 PDT Redistributed: ObjectManagementGroup-Interest:All Areas:Xerox Date: Fri, 23 May 1997 12:54:19 PDT This is in regards to the debate between Janssen and Watson on inheritance and/or subtyping. The first question for me, with my Ch1 revision hat on, is: what is the current design? It now seems clear to me that the current design has neither what Bill wants nor what Andrew wants. The fact that the GIOP uses only the simple operation names, and the fact the the current language in Ch1 vaguely suggests that operation identifiers are simple names, tells me that what Bill wants is not there now. The fact that 1.2.5 "Interfaces" currently says "Interface inheritance provides the composition mechanism for permitting an object to support multiple interfaces" (this is awkward, IMHO, but somewhat answers the question at hand), and the fact that Andrew recognizes he's promoting a debatable position, tells me that what Andrew wants is not in the current design. Agreed? The next question is: what can be changed by the ORB RTF for 2.1? It seems clear to me that neither what Bill wants nor what Andrew wants is a small enough change to do for 2.1. Agreed? The remaining questions are about what can and should be changed later. I'll think about that later. Right now, it seems to me that what Bill wants and what Andrew wants are mutually exclusive, but *I* want them both. So I'll have to think on this... Mike Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA005311AFB03740 Date: Fri, 23 May 1997 14:52:23 PDT Subject: Re: Nothing but object types To: ormsc@omg.org, orb_revision@omg.org cc: Mike_Spreitzer.PARC@xerox.com Aw damn, editing goof --- too many messages today. The provocative message I meant to include is this: ---------------------------------------------------------------- Subject: Re: terminology questions In-Reply-To: <9705221822.AA01462@radio.cme.nist.gov> Message-ID: <97May23.100003pdt."16685(9)"@alpha.xerox.com> To: edbark@cme.nist:gov Cc: orb_revision@omg:org, ormsc@omg:org From: Mike Spreitzer:PARC:Xerox Received: from emerald ([192.67.184.65]) by alpha.xerox.com with SMTP id <15193(3)>; Fri, 23 May 1997 11:41:14 PDT Received: from alpha.xerox.com by emerald (SMI-8.6/SMI-SVR4) id NAA16631; Fri, 23 May 1997 13:03:08 -0400 Received: from Gabriel.Parc.Xerox.xns by alpha.xerox.com via XNS id <16685(9)>; Fri, 23 May 1997 10:00:03 PDT Redistributed: ObjectManagementGroup-Interest:All Areas:Xerox Date: Fri, 23 May 1997 09:58:59 PDT You wrote: I take Jishnu's point that "inheritance" in IDL is basically a lexical notion: interface A : B means interface A includes all the operations defined for interface B, and does not necessarily assume that B is a "type" (another loaded word). In my view, B is a "type" exactly when it is used to characterize objects by whether or not they support the attributes and operations defined in interface B. (This is the "intentional" definition of "type" and the one used in the OM.) Not all interfaces are used in this way. In fact, in a given context, B is only a "type" if it is USED as the "type" of an attribute, parameter or result. And A can only be a "subtype" when B is a "type"... This raises an even more fundamental question. Let me warm up to it by saying that it's clear to me that there are multiple "aspects" to an interface: an interface can be used both as an object type, and as a linguistic construct (not unlike a name scope) to group together related declarations of various categories of things. I don't think it's useful to say an interface "is" a type only "where" it's used as a type, or even an interface "is" a type only *if* it's used *somewhere* as a type. Rather, let's say an interface always has a type aspect (even an interface that has no operations can be used as an object type), and always has other liguistic aspects. So here's the question: do the linguistic aspects of the "interface" concept belong in Chapter 1, or should they be entirely relegated to Chapter 3 because they only concern IDL? If you take the latter position, it seems to me that all that remains in chapter 1 is the type aspect. Which suggests we shouldn't talk (in Ch 1) about interfaces at all, only object types. Return-Path: Date: Fri, 23 May 1997 15:21:52 PDT Sender: Bill Janssen From: Bill Janssen To: michi@dstc.edu.au, soley@omg.org Subject: Re: terminology questions CC: janssen@parc.xerox.com, orb_revision@omg.org, edbark@cme.nist.gov, ormsc@omg.org References: <199705231934.PAA19151@emerald> Excerpts from direct: 23-May-97 terminology questions Richard Mark Soley@omg.o (2723) > Interesting point. However, I'm not implying that it needs to get uglier than > it already is (for C) *for that which it already supports*. Just that the > mapping to support this particular issue needn't be any worse than what is > currently done. The C mapping will already support this capability. So will the C++ mapping. I'm not sure about SmallTalk or Cobol. The Java mapping will will need extensions to cope with this, as the language itself is broken in this way. Bill Return-Path: X-Sender: genillou@dimail.epfl.ch Date: Mon, 26 May 1997 11:23:30 +0200 To: Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org From: Guy Genilloud Subject: Re: The inheritance debate [was Re: terminology questions] At 12:54 PM -0700 5/23/97, Mike_Spreitzer.PARC@xerox.com wrote: >This is in regards to the debate between Janssen and Watson on inheritance >and/or subtyping. > >The first question for me, with my Ch1 revision hat on, is: what is the >current >design? It now seems clear to me that the current design has neither what >Bill >wants nor what Andrew wants. The fact that the GIOP uses only the simple >operation names, and the fact the the current language in Ch1 vaguely suggests >that operation identifiers are simple names, tells me that what Bill wants is >not there now. Yes. There has already been a debate on this topic in the past, which made this clear. >The fact that 1.2.5 "Interfaces" currently says "Interface >inheritance provides the composition mechanism for permitting an object to >support multiple interfaces" (this is awkward, IMHO, but somewhat answers the >question at hand), and the fact that Andrew recognizes he's promoting a >debatable position, tells me that what Andrew wants is not in the current >design. Agreed? I am not sure I follow you there, and Andrew Watson is the one who should respond. The sentence you refer to is an awkward way to specify polymorphism, but it is correct. The annoying point is that it does not say that there are other ways for an object to support multiple interfaces... (Nor the opposite -- the Spec is not specific on this point.) >The next question is: what can be changed by the ORB RTF for 2.1? It seems >clear to me that neither what Bill wants nor what Andrew wants is a small >enough change to do for 2.1. Agreed? I agree. It may be worth studying ways to improve typing in CORBA, but this is too big an issue for an RTF (this is only my opinion). > >The remaining questions are about what can and should be changed later. I'll >think about that later. Right now, it seems to me that what Bill wants and >what Andrew wants are mutually exclusive, but *I* want them both. So I'll >have >to think on this... > >Mike I'd like to point out that what Bill wants (stronger type checking, to avoid accidentally calling an operation with unexpected semantics) can be obtained simply by chosing big and specific names for operations: something like _... Not elegant, but if you are really concerned... Regarding multiple-inheritance in IDL, I don't think the "diamond rule" (which says that an operation must be transitively derived from a common ancestor) is actually needed. - However, multiple inheritance of one operation should yield one operation, not several (and thus, the operation name is a sufficient identifier). - If several operation with different semantics have the same name, then multiple inheritance should be avoided. If nobody complains about removing the "diamond rule" in this way, then the RTF might remove this rule (just guessing -- what an RTF can do or cannot do is beyond me). Regards, Guy -------------------------------------------------------------------- Dr. Guy Genilloud Computer Engineering Department 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: Tue, 27 May 97 18:17:00 EDT From: edbark@cme.nist.gov (Ed Barkmeyer) To: curtis@omg.org Subject: Re: terminology questions Cc: orb_revision@omg.org, ormsc@omg.org I wrote: > >I take Jishnu's point that "inheritance" in IDL is basically a lexical > >notion: > > interface A : B > >means interface A includes all the operations defined for interface B, > >and does not necessarily assume that B is a "type" (another loaded word). > >In my view, B is a "type" exactly when it is used to characterize objects > >by whether or not they support the attributes and operations defined in > >interface B. (This is the "intentional" definition of "type" and the one > >used in the OM.) Not all interfaces are used in this way. And David Curtis says: > Sorry, but I don't have the slightest idea what you're getting at here... I am afraid that what I wrote immediately after the above was unnecessary and confusing. In the 1991 OMG Object Model, an object type is a set of constraints that characterize an instance of that type. For OMA purposes an instance of a type is characterized by its support of a specific set of operations. Each operation has a signature and an "implementation", but only the signature and the functional nature of the implementation (not its details) are characterizing for the type. That is, an operation can have more than one implementation, as long as they all do the same logical thing. All of this is an abstract specification of the concept "type". Now in IDL, an object type is mapped into an "interface", and the contents of the interface is a set of operation signatures which identify the operations that characterize the object type. Now the IDL statement: interface A : B means that every object instance of type A must support all of the operations defined in interface B. And if interface B represents a "type", that is, it identifies THE set of operations that must be supported by all object instances that are of type B, then A must be a "subtype" of B, because every instance of A satisfies the requirements for an instance of type B. We must observe that the IDL operation signature "identifies" the intended operation, but it doesn't "specify" it. So we have to depend on the comments and the good faith of the modeller to ensure that the intended function is somehow defined. Moreover, the operation signature is only required to be unique within an interface, so the same signature in another interface could identify an entirely different operation. (This last is why Bill makes the point that B::op1() and C::op1() can legitimately identify two different operations, both of which are inherited by a common subtype A, but the IDL does not permit that.) Unfortunately, not everyone plays by the above rules, and thus two problems arise: (1) As Mike observed, some "interfaces" are not the representation of "types". Rather they are treated as lexical groups of operation signatures. No one cares about the collection of object instances that supports that interface; the interface is just a group operation signatures that is imported as a group into another interface specification. These are sometimes called "mix-ins" or "convenience interfaces". (2) In a similar way, some "operation signatures" do not identify specific operations. Rather the signature is imported into an interface and it acquires a specific interpretation there. The C++ "virtual method", which is similar, has a specific implementation for a specific subtype, but the "nature of the function" is presumed to be the same. Unfortunately, because of (1), all that is required in IDL is that the signature is the same; the sense may be entirely different. Now, like Bill and others, I would characterize both of these latter problems as "misuse" of IDL, inconsistent with the intent of the OMG object model. That doesn't mean that the platform software has to diagnose them. It just means that we don't write the object model in terms of what the platform software allows and can accidentally use to do something that may be meaningful. Rather we define in the Object Model the notions that the IDL, and other platform conventions like IIOP, were INTENDED to support. I think I have come 180 degrees from where I was last week. If "inheritance" has come to mean "lexically imported" in OMG, that is NOT A GOOD THING. The object model should make clear that "inherits from" is an object notion that implies "is a subtype of". However, the question that Andrew raised is the converse: Does "is a subtype of" imply "inherits from"? And again the answer must be YES, from the abstract point of view. If A is a subtype of B, then A must inherit (i.e. support) all the operations defined for B. But the position stated by Bill Janssen and seconded by others, including Richard, is that interface A : B must appear in the IDL definition of A for A to be a subtype of B. This is not "obviously true" -- all that is really required for A is that every instance support the operations on B -- but we may want to REQUIRE this syntax in order to that X "knows" that A is a subtype of B. But the question is: Who is X? The ORB? If we see the IDL specification as a document more valuable than an input to the ORB compiler, then of course, we can state that it is "best practice" to state "subtype" as IDL "inheritance". But from the point of view of the "platform" standards, it is not clear to me that there is as yet a reason why the ORB should care how the IDL was modularized, as long as the A objects support the B operation signatures. What Andrew and David have pointed out is that the current OMG specs allow the platform to care about even less than that. Now, IF we consider Bill and Richard's recommendation that the IDL and the ORB implementations should support operation names qualified by interface names, so that interface A : B, C is allowed and A can inherit BOTH B::op1 and C::op1, THEN the way in which the IDL is written will affect the identification of the operation itself! A::op1 is not the same operation name as B::op1, and if an instance of A is intended to support B::op1, then it must be written interface A : B. It does NOT suffice just to have the op1 signature in the interface A. And in this light, I can understand Bill's concern. Is this where we really want to be going? It makes sense, but it sure would have been nice if we had told the platform vendors BEFORE v2.0! -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 Return-Path: X-Sender: genillou@dimail.epfl.ch References: <9705272217.AA01845@radio.cme.nist.gov> Date: Wed, 28 May 1997 15:55:29 +0200 To: Mike_Spreitzer.PARC@xerox.com, edbark@cme.nist.gov From: Guy Genilloud Subject: Re: terminology questions Cc: curtis@omg.org, orb_revision@omg.org, ormsc@omg.org In this message, I have provided a list of arguments for NOT revising the subtyping rules within a general revision process! The issue is probably wider than most people realize... At 5:15 PM -0700 5/27/97, Mike_Spreitzer.PARC@xerox.com wrote: >... >Actually, my point is that an interface, in *addition* to specifying an object >type, is *also* a lexical construct, for collecting together various things >*besides* operations, such as exceptions, constants, and other types (both >object types and non-object types). And I suspect this means the lexical >aspect should be banished from Chapter 1, leaving only the object type notion, >detached from "interfaces" (which must be relegated to Chapter 3, being >linguistic constructs). ... The discussion is making clear that not all "IDL interfaces" are interface types, and that IDL was not specifically conceived for defining types and subtypes. (1) I see this as a strong argument for NOT taking a fast decision that "is a subtype of" from now on will imply "inherits from". Other arguments for not taking a fast decision on the matter of subtyping include: (2) In open distributed systems, we can't "just recompile". And we need to define scalable solutions. My point is that if OMG takes the position that subtyping implies inheritance in IDL, then it might become impossible to revise a clumsy inheritance hierarchy (one can only add new leaves, not insert new nodes in the middle). (3) The OSI Systems Management Architecture is registering all operation (in fact, actions and attributes) names with unique identifiers (OIDs) -- this is analog to what would be required for identifying "IDL interfaces" if OMG were to decide subtyping implies inheritance in IDL. The experience in OSI is that using OIDs is not without problems: it happens in practice that operations that have the same semantics have different OIDs (e.g., operations get a new OID when they get endorsed by a standards body). When that happens, the communications infrastructure prevents interoperability even though the types are the same... (4) There is a body of type theory that suggests that inheritance and subtyping are better kept separate (yes, even considering interface inheritance). I find interesting that in the distributed objects language Emerald, subtyping does not imply interface inheritance (and I know that the designers of Emerald care a lot about typing). Can OMG just ignore all this work? > >The question is not "who knows that A is a subtype of B": any party with >both A >and B in hand can determine whether A is a subtype of B by static examination, >regardless of which of the options being discussed is taken. > >I think we're agreed that A must support the operations on B. A central >question is: how are those operations identified --- by simple name like >"op1", >or compound identifier like "B::op1"? Whatever answer you take, you have to >follow through. If the answer is "compound identifiers like B::op1", >then: (1) >the IIOP has to pass such identifiers on the wire (it doesn't now, so >switching >to this answer breaks all existing IIOP implementations), and (2) if we >want to >allow A to be a subtype of B without using the explicit inheritance construct, >we have to allow the author of A to write "B::op1" instead of just "op1" >in the >signature for that operation (and if the author is able to do this, why >couldn't he just use the explicit inheritance construct instead?). (5) Not breaking all existing IIOP implementations is a good reason for NOT revising the subtyping rules within a general revision process. It may not be the best reason, but it is probably the strongest (the one that will convince most people). As I pointed in a preceding message, the issue of whether the so-called diamond rule might be removed or not is a different issue (provided it is resolved without changing the current subtyping rules). I do not think that this rule is actually needed. Regards, Guy -------------------------------------------------------------------- Dr. Guy Genilloud Computer Engineering Department 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: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA006EEAC8423731 Date: Wed, 28 May 1997 07:37:52 PDT Subject: Re: terminology questions To: guy.genilloud@di.epfl.ch cc: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org, ormsc@omg.org > I see this as a strong argument for NOT taking a fast decision that > "is a subtype of" from now on will imply "inherits from". I do not think it's a good idea to make major changes hastily (and expect that any attempt to do so would be swatted down in the OMG processes). I'm not sure I understand your statement quoted above. Are you suggesting that CORBA now specifies an object subtyping relationship that is more liberal than "inherits from"? Or that CORBA only specifies that inheritance implies subtyping, leaving vendors to decide whether subtyping implies inheritance in their products? I think the latter is the case. I know of at least one "vendor" that has indeed chosen to make subtyping imply inheritance. Also, I'm not sure I understand what you mean by "from now on". Forever is a *long* time. I think the proper questions are framed in terms of scope: what can be changed when? What can be changed for 2.1? For 2.2? For later 2.X? For 3.0? IMHO, neither the change Watson wants nor the change Janssen and Soley have been advocating can be made for 2.1 (if these are indeed *changes*). *When* do you think we could change the IIOP to pass compound operation identifiers (if we decided we want to)? Return-Path: X-Sender: soley@emerald.omg.org Date: Wed, 28 May 1997 11:09:17 -0400 To: Mike_Spreitzer.PARC@xerox.com From: Richard Mark Soley Subject: Re: terminology questions Cc: ormsc@omg.org, guy.genilloud@di.epfl.ch, orb_revision@omg.org >IMHO, >neither the change Watson wants nor the change Janssen and Soley have been >advocating can be made for 2.1 (if these are indeed *changes*). To be perfectly clear: I agree with you Mike. In particular I do *not* want to go making functional changes by changing only the object model materials! -- Richard Return-Path: X-Sender: genillou@dimail.epfl.ch References: Date: Wed, 28 May 1997 19:52:26 +0200 To: Mike_Spreitzer.PARC@xerox.com From: Guy Genilloud Subject: Re: terminology questions Cc: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org, ormsc@omg.org At 7:37 AM -0700 5/28/97, Mike_Spreitzer.PARC@xerox.com wrote: >> I see this as a strong argument for NOT taking a fast decision that >> "is a subtype of" from now on will imply "inherits from". > >I do not think it's a good idea to make major changes hastily (and expect that >any attempt to do so would be swatted down in the OMG processes). I'm not >sure >I understand your statement quoted above. Are you suggesting that CORBA now >specifies an object subtyping relationship that is more liberal than "inherits >from"? Or that CORBA only specifies that inheritance implies subtyping, >leaving vendors to decide whether subtyping implies inheritance in their >products? I think the latter is the case. I know of at least one "vendor" >that has indeed chosen to make subtyping imply inheritance. The fact that one ORB makes subtyping imply inheritance is news to me. The question was asked last year on the email, and no product came up with this answer (although some companies regretted it...). Does their solution work also in a federation, i.e., when using IIOP to access another ORB? I support the idea that things need to be said simply and clearly (and I appreciate your efforts with that respect). So I think the spec should have a Note saying that: "CORBA only specifies that inheritance implies subtyping. Whether subtyping implies inheritance is currently not specified... (and something about the fact that IIOP does not pass compound operation identifiers)" Maybe Andrew Watson could help us here, to state precisely what is specified explicitly or implicitly, or not specified at all. >Also, I'm not sure >I understand what you mean by "from now on". Forever is a *long* time. I >think the proper questions are framed in terms of scope: what can be changed >when? What can be changed for 2.1? For 2.2? For later 2.X? For 3.0? IMHO, >neither the change Watson wants nor the change Janssen and Soley have been >advocating can be made for 2.1 (if these are indeed *changes*). *When* do you >think we could change the IIOP to pass compound operation identifiers (if we >decided we want to)? I answered your questions because I was concerned that most people were not aware of all the implications (i.e., changing the typing issue was going to imply significant changes). As a University member, I am not qualified to make decisions. Nevertheless, I would like to point out that the ORMSC has a working group on the issue of typing, where this issue can be discussed, documented, and put forward to the AB. There are probably other ways to go about it (e.g., draft an RFP). Best Regards, Guy -------------------------------------------------------------------- Dr. Guy Genilloud Computer Engineering Department 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, 28 May 1997 14:03:19 -0500 From: Gary Daugherty To: Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch Subject: Re: The inheritance debate [was Re: terminology questions] Cc: gwdaughe@cca.rockwell.com To all, Personally I would like to see: 1) IDL offer a means for specifying the semantics of services in a pre/post/ invariant style 2) resolution of name clashes and issues related to repeated inheritance as in Eiffel Regarding an earlier issue raised with respect to the quality/cohesion of interfaces, I contend that it should be possible to come up with a reasonable set of objective guidelines for coupling and cohesion iff we take steps to specify the semantics of services (as suggested above). Sincerely, Gary Daugherty Rockwell International Return-Path: Date: Wed, 28 May 1997 12:43:41 PDT Sender: Bill Janssen From: Bill Janssen To: guy.genilloud@di.epfl.ch, Mike_Spreitzer.PARC@xerox.com Subject: Re: terminology questions CC: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org, ormsc@omg.org References: <97May28.073828pdt."15958(4)"@alpha.xerox.com> Excerpts from local.omg: 28-May-97 Re: terminology questions Mike_Spreitzer.PARC@xero (1232) > *When* do you > think we could change the IIOP to pass compound operation identifiers (if we > decided we want to)? It could have been changed for IIOP 1.1. We considered allowing (not requiring) operation identifiers of the form "[:]" for 1.1, but decided that the additional error checking wasn't worth it, as the IDL was still constrained by the silly inheritance restriction. Bill Return-Path: Date: Wed, 28 May 97 16:02:55 EDT From: edbark@cme.nist.gov (Ed Barkmeyer) To: Mike_Spreitzer.PARC@xerox.com Subject: Re: terminology questions Cc: orb_revision@omg.org, ormsc@omg.org EXECUTIVE SUMMARY: I accept Mike's corrections to what I said, and I don't think we are far from agreement, for what that's worth. vv - "type" and "subtype" are Chapter 1 notions - "inherits from" is an IDL notion, (if OA&D will tolerate that) - every type is modelled as an interface, but not every interface is the model of a type - we probably do need to say something about operation signatures and their related semantics (and scope?) -- partial specification - fixing multiple inheritance and operation naming is not in the OM scope of work. Proposal (Andrew?): - modelling subtype as "inherits from" in IDL is good practice, but not every subtype is modelled as "inherits from", and not every "inherits from" is the model a subtype. Alternative (Bill?): - every subtype is modelled as "inherits from", but not every "inherits from" is the model a subtype. I don't care which of these we choose, but maybe I should. I am trying to understand who does and why. -------------------------------------------------------------------------- Detailed discussion, for those who have the stomach for this stuff. I wrote: > > (1) As Mike observed, some "interfaces" are not the representation of > > "types". Rather they are treated as lexical groups of operation signatures. > .. And Mike responded: > Actually, my point is that an interface, in *addition* to specifying an object > type, is *also* a lexical construct, for collecting together various things > *besides* operations, such as exceptions, constants, and other types (both > object types and non-object types). And I suspect this means the lexical > aspect should be banished from Chapter 1, leaving only the object type notion, > detached from "interfaces" (which must be relegated to Chapter 3, being > linguistic constructs). So when I said: > > Now, like Bill and others, I would characterize both of these latter > > problems as "misuse" of IDL, inconsistent with the intent of the OMG > > object model. Mike answers: > Re (1): If putting things besides operations in an interface is a misuse, then > much of the OMG is guilty. For example, Chapter 6 says that CORBA::Contained > includes a type, "Description". Quite right. I misspoke. And I agree that "interface" is a lexical issue and should not be in Chapter 1. This makes it important to realize that: Every "type" is represented by an "interface", but NOT EVERY "interface" represents a "type". (And you can't tell from the IDL, my previous comments notwithstanding.) (BTW, I await the Chapter 1 definition of the concept "non-object type". Being a Smalltalk person, I have a hard time understanding this as anything but an implementation distinction. Nijssen (1977) distinguished "lexical objects" (things that have a hardware representation) from "non-lexical objects" (what we call "objects"), which is a bit closer.) > > (2) In a similar way, some "operation signatures" do not identify > > specific operations. Rather the signature is imported into an interface > > and it acquires a specific interpretation there. > > While the OMG mechanisms don't prevent this, it sounds like bad modelling > practice to me. I agree, as I said. > I think it makes more sense to say an operation is partially > specified where it is introduced. Always, period. This is true, but unfortunately "is introduced" seems to be a syntactic notion, and thus this restatement doesn't say anything different. The assumption that there is more or less semantics in the operation signature and surrounding commentary is in the eye of the modeller. What we are both trying to say is that good practice demands that there be "strong semantic inheritance" along with the inheritance of the signature. > Derived interfaces may add > details (but not contradicting details) to the partial specifications of > operations they inherit. ... > > Re (2): I might believe that bad modelling practice is not intended by the OMG > object model. I can't believe that partial specifications are not intended. I originally took your term "partial specification" to mean just that: the signature tells us some things but not others. But it seems you use the term in a broader sense. My only concern is that the Chapter 1 notion "operation" is not equal to "operation signature + implementation", as it is in C++, but rather to "operation signature + functional description" (WHAT it does, but not HOW it does it). The mapping to IDL only captures the signature, but it implies the functionality. > > However, the question that Andrew raised is the converse: > > Does "is a subtype of" imply "inherits from"? And again the answer must > > be YES, from the abstract point of view. If A is a subtype of B, then > > A must inherit (i.e. support) all the operations defined for B. > > You're using the word "inherit" in a way that obscures the point of Andrew's > question. You're giving "inherit" essentially the same definition as > "subtype". Let's not. I think the rest of us are using "inherit" to mean > "explicitly uses the IDL inheritance construct". OK. That was Jishnu's original point -- that "inherits" is an IDL notion, not a Chapter 1 notion. I can live with this. Do you think the OA&D gang can? In the same way, then, "subtype" is a Chapter 1 notion and NOT an IDL notion. We can rephrase the two postulates: (a) Does "inherits from" (in IDL) imply "is a subtype of"? Answer: NO, for just the reasons Mike gives above. (b) MUST "is a subtype of" be represented by "inherits from" in IDL? i.e. > > interface A : B > > must appear in the IDL definition of A for A to be a subtype of B. > > This is not "obviously true" -- all that is really required for A is > > that every instance support the operations on B -- but we may want to > > REQUIRE this syntax in order that X "knows" that A is a subtype of B. > > But the question is: Who is X? The ORB? Mike says: > The question is not "who knows that A is a subtype of B": any party with both A > and B in hand can determine whether A is a subtype of B by static examination, > regardless of which of the options being discussed is taken. Now it is my turn to say I don't follow this. I can read the above to say that no one who needs to know cares how "subtype" is represented in IDL. It seems to me we could say: If A is intended to be used as a subtype of B, then the IDL should be written: interface A : B. And no one will object. But what I understood Bill to request is the statement: If A does not inherit from B, then nothing should treat A as a subtype of B. Andrew's point, if I got it right, is that the one agent that that rule seems to affect does not currently abide by that rule, and may not be able to. I don't feel strongly either way. My question is: Who cares how it is represented, and why? (Am I wrong to infer that your answer above means "no one"?) > A central question is: > how are those operations identified --- by simple name like "op1", > or compound identifier like "B::op1"? Exactly. And my point was that IF you require B::op1, THEN it DOES make a difference HOW the "subtype" notion is represented in IDL. If only "op1" is used to identify the operation on B, then EITHER interface A : B OR interface A { void op1(...); is consistent with A being a subtype of B -- it supports "op1". But if B::op1 is the identifier for the operation, then A::op1 is NOT. You have to have some way to have B::op1 be an operation on A. I thought "inherits from" was the only way to get the subtype semantics. But Mike says: > (2) if we want to allow A to be a subtype of B without using the explicit > inheritance construct, we have to allow the author of A to write "B::op1" > instead of just "op1" in the signature for that operation > (and if the author is able to do this, why > couldn't he just use the explicit inheritance construct instead?). I hadn't thought of this trick, but I agree it makes little sense. My point, however, was that this seems to be the ONLY REASON for worrying about whether "subtype" is modelled as "inherits from". If this is indeed a separable question, as Mike indicates, then why do we care? Mike also says: > Whatever answer you take, you have to > follow through. If the answer is "compound identifiers like B::op1", then: > (1) the IIOP has to pass such identifiers on the wire (it doesn't now, so > switching to this answer breaks all existing IIOP implementations), and Yup. That is why I said we should have made this change before V2 if we intended to do it. And I completely agree with Richard that the ORMSC is not the place to work on changes that affect the IDL and IIOP. -Ed Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA006EEAC8493731 Date: Wed, 28 May 1997 13:10:51 PDT Subject: Re: terminology questions To: guy.genilloud@di.epfl.ch cc: Mike_Spreitzer.PARC@xerox.com, orb_revision@omg.org, ormsc@omg.org > The fact that one ORB makes subtyping imply inheritance is news to me. > ... > Does their solution work also in a federation, i.e., when using IIOP to > access another ORB? It seems clear to me that when a vendor offers a more liberal subtyping relationship than that *required* by CORBA, programs written against that more liberal relationship *can not* be expected to be portable across all CORBA implementations. The *only* programs that *are* portable are those that rely on *only* what CORBA *requires*. Thus, a vendor that makes the subtyping relationship hold *only* in cases of inheritance gives his users no portability problems (every subtyping relationship that holds for that vendor's system also holds for all other CORBA systems); it's all the other vendors (and their users) that have to worry about portability problems. Return-Path: X-Sender: kpt@pop.galaxy.net Date: Wed, 28 May 1997 18:48:18 -0400 To: Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch From: "Kevin P. Tyson" Subject: Re: The inheritance debate [was Re: terminology questions] Cc: gwdaughe@cca.rockwell.com At 15:03 -0400 5/28/97, Gary Daugherty wrote: >To all, > >Personally I would like to see: > >1) IDL offer a means for specifying the semantics of services in a pre/post/ > invariant style As would I. You might want to take a look at two documents on the OMG server. The first is authored by Desmond D'Souza and Alan Wills. I don't have the document number but it was posted in December 1995. It was a response the OMG's RFI on Object Analysis and Design. In it they say, "We see the next step as being the extension of IDL to cover behavioral specification (rather than just signatures); and the definition of a common linguistic basis between developer's support tools, so that they can exchange information about component interfaces and architectures. We will refer to this (future) language as IDL++." The second document is 95-12-12 and is titled, "Object Analysis and Design. The Eros group's RFI response" by Iain Houston and Alan Wills where they also call for behavior specifications in IDL. Best regards, Kevin -- Kevin P. Tyson Enterprise Engineering Associates, 18 Foxcroft Drive, Marlboro NJ 07746-1664 http://www.enteng.com/ mailto:kpt@enteng.com voice:908.972.3421 fax:908.972.9349 page:800.279.3150 pin:99627 Return-Path: X-Sender: andrew@emerald.omg.org Date: Wed, 28 May 1997 19:48:42 -0400 To: Mike_Spreitzer.PARC@xerox.com From: Andrew Watson Subject: Re: The inheritance debate [was Re: terminology questions] Cc: ormsc@omg.org, orb_revision@omg.org, Mike_Spreitzer.PARC@xerox.com Mike, You wrote: > The first question for me, with my Ch1 revision hat on, is: what is the > current design? It now seems clear to me that the current design has > neither what Bill wants nor what Andrew wants. The fact that the GIOP > uses only the simple operation names, and the fact the the current > language in Ch1 vaguely suggests that operation identifiers are simple > names, tells me that what Bill wants is not there now. Agreed. And I'd attach more weight to the concrete language in GIOP 1.1 than the vague language in Chapter 1. > The fact that 1.2.5 "Interfaces" currently says "Interface > inheritance provides the composition mechanism for permitting an object to > support multiple interfaces" (this is awkward, IMHO, but somewhat answers > the question at hand), and the fact that Andrew recognizes he's promoting > a debatable position, tells me that what Andrew wants is not in the > current design. Agreed? Not really. I know I'm promoting a debatable position because, er, people keep debating it. The direct consequence of the relevant section in GIOP 1.1 is to allow non-inheritance substitutability. The language in CORBA chapter 1 always was ambiguous on this point, but if it was left up to me it would now be made to align with GIOP 1.1 in stating unambiguously that interface inheritance is not a necessary condition for substitutability. > The next question is: what can be changed by the ORB RTF for 2.1? It > seems clear to me that neither what Bill wants nor what Andrew wants is a > small enough change to do for 2.1. Agreed? Again I'd beg to differ. Fixing Chapter 1 to align with GIOP 1.1 just corrects an ambiguity in Chpter 1. Adding about two sentences ought to do it. GIOP wouldn't need changing at all. Cheers, Andrew Return-Path: X-Sender: andrew@emerald.omg.org References: <199705281903.OAA04662@basie.cca.rockwell.com> Date: Wed, 28 May 1997 19:59:45 -0400 To: "Kevin P. Tyson" From: Andrew Watson Subject: Re: The inheritance debate [was Re: terminology questions] Cc: Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch Kevin, You wrote: > >Personally I would like to see: > > > >1) IDL offer a means for specifying the semantics of services in a > > pre/post/invariant style > > As would I. > > You might want to take a look at two documents on the OMG server. The > first is authored by Desmond D'Souza and Alan Wills. I don't have the > document number but it was posted in December 1995. It was a response the > OMG's RFI on Object Analysis and Design. In it they say, "We see the next > step as being the extension of IDL to cover behavioral specification > (rather than just signatures); and the definition of a common linguistic > basis between developer's support tools, so that they can exchange > information about component interfaces and architectures. We will refer to > this (future) language as IDL++." > > The second document is 95-12-12 and is titled, "Object Analysis and > Design. The Eros group's RFI response" by Iain Houston and Alan Wills > where they also call for behavior specifications in IDL. It seems to me that we now have 3 questions being considered simultaneously: 1) Is representing object semantics at run time a Good Thing? My answer - Yes, quite clearly. 2) Should IDL be extended to represent object semantics in addition to describing interaction structure and datatypes? My answer - maybe. Another option would be to create separate description languages for semantics, to be used in parallel with IDL. This is attractive because there are all sorts of dimensions to "semantics" that we might want to represent (including pre- and post- conditions), and no one set is going to please everyone. 3) Should we attempt to use IDL interface inheritance to represent semantics? My answer - clearly no. Inheritance graphs are far too weak a representational mechanism for this, and trying to use them to solve part of the problem is no help. Let's leave inheritance to one side, as a useful way of writing smaller IDL files, and address the semantics description problem with a clean sheet. Cheers, Andrew Return-Path: X-Sender: carolbrt@mindspring.com Date: Wed, 28 May 1997 20:49:51 -0500 To: Andrew Watson , "Kevin P. Tyson" From: Carol Burt Subject: Re: The inheritance debate [was Re: terminology questions] Cc: Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch References: <199705281903.OAA04662@basie.cca.rockwell.com> Hi, Well I can't resist any longer... In reply to Kevin's message, Andrew wrote: >2) Should IDL be extended to represent object semantics in addition to > describing interaction structure and datatypes? > > My answer - maybe. Another option would be to create separate > description languages for semantics, to be used in parallel with IDL. > This is attractive because there are all sorts of dimensions to > "semantics" that we might want to represent (including pre- and post- > conditions), and no one set is going to please everyone. I agree. First let me say that I think we will eventually want to add some minimal amount of semantics to IDL. HOWEVER, my bias is that it be limited to what is necessary to ensure interoperability of independently developed implementations when appropriate(ie, we want to federate Traders, Naming Services, Patient Identification Services). It also remains to be seen what, if anything, will happen at the IDL level for a Component Model which obviously must be "well behaved". In some sense, it is the line between interface and implementation which is being discussed. It could be considered a feature that, in different environments, I can implement the same IDL with diverse semantics.... It is clearly necessary to understand the semantics of an implementation in order to use it... but it is clearly not a reasonable goal to fully define semantics in IDL. If you could, you'd have defined a programming language and you could merely generate the implementation for your favorite language and compile it. It's hard enough to design interfaces "by committee", imagine designing implementation that way. This has been my concern about "some of" (not your's Kevin) the semantic discussions I've been involved in.... they tend to frighten me as they wander beyond the practical into academia. Andrews suggestion of a separate descriptive language for semantics is very attractive. The question then becomes: What do we adopt as technology? What does it mean to conform... are the semantic definitions part of the specification? I'm biased toward adopting IDL which has the minimal extensions I mentioned above.... if for no other reason than I think agreeing on "semantics" in a large diverse organization with many different viewpoints (ODP pun intended) isn't a goal we are likely attain. > >3) Should we attempt to use IDL interface inheritance to represent > semantics? > > My answer - clearly no. Inheritance graphs are far too weak a > representational mechanism for this, and trying to use them to solve > part of the problem is no help. Let's leave inheritance to one side, > as a useful way of writing smaller IDL files, and address the semantics > description problem with a clean sheet. > If we wanted to do this, the (non-existant) typing system debate should be resolved first :-) Debate has raged on this without resolution - or with the resolution that there is no typing system - for as long as I can remember (the ember's never go out and the flames erupt from time to time as they have recently). I've tended to agree with Andrew that subtyping and inheritance should be distinct... which obviously means that there are no semantics implied by the inheritance graph today, nor should there be. Carol ____________________________________________________________________ Carol Burt cburt@2ab.com 2AB, INC. 205-250-6392 2AB specializes in Integration Architecture using CORBA technology! Return-Path: X-Sender: kpt@pop.galaxy.net (Unverified) References: <199705281903.OAA04662@basie.cca.rockwell.com> Date: Wed, 28 May 1997 21:57:58 -0400 To: Andrew Watson From: "Kevin P. Tyson" Subject: Re: The inheritance debate [was Re: terminology questions] Cc: Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch Andrew, You wrote: >1) Is representing object semantics at run time a Good Thing? > > My answer - Yes, quite clearly. After having represented and refined them during analysis, design and coding. Their representation at run time is key to enforcement of our intentions but we need them all the way through if we are ever going to have a real component-based technology. >2) Should IDL be extended to represent object semantics in addition to > describing interaction structure and datatypes? > > My answer - maybe. Another option would be to create separate > description languages for semantics, to be used in parallel with IDL. > This is attractive because there are all sorts of dimensions to > "semantics" that we might want to represent (including pre- and post- > conditions), and no one set is going to please everyone. The purist in me wants to extend IDL but there are good reasons not to do so. One practical reason is that the vendors will be loath to extensively modify their products without clear market pressure. Another is that IDL is static and hence would have a hard time with dynamic systems like Event-Condition-Action rules or Actor-based systems. > >3) Should we attempt to use IDL interface inheritance to represent > semantics? > > My answer - clearly no. Spot on. Let's leave this battle to Bertrand Meyer ;-) Best regards, Kevin -- Kevin P. Tyson Enterprise Engineering Associates, 18 Foxcroft Drive, Marlboro NJ 07746-1664 http://www.enteng.com/ mailto:kpt@enteng.com voice:908.972.3421 fax:908.972.9349 page:800.279.3150 pin:99627 Return-Path: Date: 28 May 1997 22:56 EDT Sender: "Rainer Kossmann" To: andrew@omg.org Cc: kpt@enteng.com, gwdaughe@cca.rockwell.com, Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch From: "Rainer Kossmann" Subject: Re: The inheritance debate [was Re: terminology questions] In message "Re: The inheritance debate [was Re: terminology questions]", 'andrew@omg.org' writes: >Kevin, > >You wrote: > >> >Personally I would like to see: >> > >It seems to me that we now have 3 questions being considered simultaneously: >1) Is representing object semantics at run time a Good Thing? > > My answer - Yes, quite clearly. > It is essential, with emerging requirements for continuous 24/7/365 operation, coupled with local autonomy on upgrades, including additions to / extensions of the run-time semantic system. This does not mean that the system MUST become interpretive / reflective, it just means that the semantics are available at run-time if and when required. It is a relatively minor decision whether the system should remain interpretive / reflective, whether to compile out the reflection at compile-time, or whether to just-in-time compile it out at link / load / run-time. >2) Should IDL be extended to represent object semantics in addition to > describing interaction structure and datatypes? > > My answer - maybe. Another option would be to create separate > description languages for semantics, to be used in parallel with IDL. > This is attractive because there are all sorts of dimensions to > "semantics" that we might want to represent (including pre- and post- > conditions), and no one set is going to please everyone. > RM-ODP talks about Viewpoints, the semantics of each Viewpoint, and that semantics is ultimately always specified in Language. It may make sense in some cases to have a direct coupling between a Language and a Viewpoint, such as for example using SQL-3 or ODL as a basis for the (future) Information Viewpoint. In other cases, existing languages may already contribute at least partially towards the semantics of a number of different viewpoints; for example, it may be argued that Ada Package notions etc. are concerned with 'component' and hence the Engineering / Technology Viewpoint. Ie. there are "impurities" already in the existing schemes. In yet other scenarios, one might argue that there is such a thing as say a "Security Perspective", which in many ways looks, feels, ... just like an RM-ODP Viewpoint, and that the Security Perspective is expressible in a 'Security Language' such as the GRANT ... language subset of SQL-3 for example. Bottom line is that this semantic information is effectively Meta- Information (generally first order MetaInformation that reflectively governs and controls system behaviour and operation) and hence probably ultimately within the purview of the MetaObjectFacility (MOF). (Note though that the reflection may be compiled out by the compiler, linker, loader, just-in-time run-time compiler). The run-time existence of this MetaInformation /Semantics in the MOF, as a collection of MetaObjects, with associated MetaFunctions used to manage it (ie. a MetaService), means that there is probably a coupling between: - language constructs used to populate the MOF, and their associated compilers (eg. C++ compiler; eg. IDL->C++ compiler, ...) - a Services Interface to a MOF Viewpoint / Perspective, that can be used to populate / manage / examine the appropriate MOF-resident Viewpoint / Perspective (eg. a Security Interface -- providing the run-time accessible Security MetaFunctions to manage the Security MetaObjects), and that furthermore, we should suspect that the RM-ODP partitioning into 5 viewpoints should probably be considered as an architecturally flexible, evolutionary 'n' Viewpoints / Perspectives that can flex and bend as expertise and requirements change. Ie. I suspect that the notion of Viewpoint / Perspective should itself be open, and that language / semantic / services couplings between Viewpoint / Perspective also remain open and amenable to change. This implies that the semantically complete architecture would accomodate a future Security Language / Security Viewpoint / Security Interface, if that is the direction in which the world wanted to move. Ie. I do not attach any specific significance to the magic number 5. It is however an excellent starting point. There is a stab at the above ViewPoint (MetaViewPoint???) in OMG document internet/96-06-12. >3) Should we attempt to use IDL interface inheritance to represent > semantics? > > My answer - clearly no. Inheritance graphs are far too weak a > representational mechanism for this, and trying to use them to solve > part of the problem is no help. Let's leave inheritance to one side, > as a useful way of writing smaller IDL files, and address the semantics > description problem with a clean sheet. > > Cheers, > > Andrew > > ---------------------------------------------------------- Regards, | Rainer Kossmann | VoiceMail: (613) 765-5915 | | Nortel Technologies | VoiceCall: (613) 726-3126 | Rainer | P.O. Box 3511, Station C | Fax : (613) 726-3126 | | Ottawa, Ontario | Email : Kossmann@Nortel.CA | | Canada K1Y 4H7 | | ---------------------------------------------------------- Return-Path: Date: Wed, 28 May 1997 20:49:17 PDT Sender: Bill Janssen From: Bill Janssen To: Andrew Watson , "Kevin P. Tyson" , Carol Burt Subject: Re: The inheritance debate [was Re: terminology questions] CC: Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch References: <199705281903.OAA04662@basie.cca.rockwell.com> <3.0.2.32.19970528204951.006bee28@mindspring.com> Mike, Guy, Andrew, Carol, Kevin, Gary: I have no particularly strong objections to most of the solutions I've heard proposed, but I'm not sure they actually achieve what needs to be achieved. Let me try to set out my requirements without regard to ``typing'', since I'm not sure ``type'' has any useful meaning with respect to OMG IDL interfaces. My concerns are purely about engineering systems of the size which the Xerox Corporation needs to build, not about philosophy of object systems or the beauty of object systems. I will try to avoid the use of ``method'' and ``object'', as I believe that we are really talking about operations on remote services. Please consider my points below in parallel; though I have to explain them serially, they need to be addressed simultaneously. 1) We need to be able to precisely specify the particular operation we wish to invoke, both in language mappings and across the wire. The current charming ambiguity of operation names can lead to extremely difficult-to-diagnose errors in any large distributed system. This problem can be solved in a variety of ways. As both I and M. Genilloud pointed out, we can simply ignore the name or ID of the interface in which the operation is defined, and ``name'' it with a unique ID. This approach seems cumbersome, particularly with regard to the way that language mappings might express that operation name, but would work as well as anything across the wire [well, not really, but I'll leave it as an exercise to the reader to discern why.], and would function with the current OMG IDL spec. [It might also expose the CORBA system to minor ridicule from proponents of competing systems, but perception and marketing problems are not engineering problems, are they?] A variation of this would asssign two names to the operation, one ``raw'' and another a UUID; the raw name would be used in the language mapping, and the UUID would be used in IIOP. This suffers from not allowing explicit identification of an operation in the language mapping. Still another approach, which seems less cumbersome to me (and likely to users) would be to implicitly qualify the ``raw'' name of the operation with the name or ID of the interface in which it's defined. This has the drawback of defeating the ``painless rearrangement of poorly designed inheritance hierarchies'' which Watson and Genilloud deem important. (I wish they'd present a stronger case demonstrating that this is in fact important.) 2) We need to provide a mechanism to potential client to discern whether or not a particular service supports a set of interfaces. The important thing here is not about typing; it is about allowing a client to efficiently discern that this remote service supports this set of interfaces. This is important for versioning, for error-checking, for higher-level protocol negotiation. In an Internet (or global-enterprise Intranet) setting, minimizing round trips and latency is very important, as is minimizing the actual number of bytes transferred. A potential user could certainly individually query a service about each operation it's interested in (provided we have some way to unambiguously identify operations), or about each interface it's interested in. It could even inquire about a set of interfaces at once, as DCOM does. CORBA does not have the QueryMultipleInterfaces call that DCOM does, but it does have something that works even better in most cases. It has multiple inheritance. That is, by checking whether a service supports a particular interface X (using "is_a"), we can implicitly check that it supports all of the interfaces inherited into X. This has an advantage over the DCOM QueryMultipleInterfaces of requiring fewer bytes ``on the wire''. An alternative would be to add one or more built-in operations to CORBA, similar to "is_a", to allow a potential client to test whether a service supports some set of operations ("has_operations"), or whether it supports some set of interfaces ("has_interfaces"), without necessarily involving inheritance. Either of these approaches would decouple the inheritance trees of the service provider and the service user, but each would consume many more bytes on the wire. The "has_interfaces" call would still be useful even if we retain current inheritance notions, as a way of reducing round trips and system latency. 3) We need to be able to export arbitrary multiple interfaces from a service. This is a checklist item for enterprise-wide distributed systems technology. The currently specified way of doing this is to define an OMG IDL interface X which inherits from all of these other interfaces, thereby aggregating them or gathering their operations or whatever. This X interface often defines no additional operations of its own; it just acts as a container for the other interfaces. Those interfaces will, by Murphy's law, be defined by standards organizations, competitors, or other divisions within the enterprise which have no intention of modifying them to help our organization. We cannot allow clashes of raw operation names within the inherited interfaces to prevent this aggregation, as is currently the case. 4) In all likelihood, we will continue to use Repository IDs as the ``real'' names for things, whether those things are interfaces or operations. We need to either discard or fix the ``IDL'' repository ID format so that we cannot have accidental clashes between IDs generated by non-cooperating bodies. This critically affects our capabilities [and credibility, but that's marketing] with respect to interoperability, scaling, and error detection (think quality assurance). I would suggest that we replace all ``IDL'' format IDs in the CORBA spec with a format that cannot have accidental clashes -- the only currently defined format with that property is the ``DCE'' format, which would work perfectly well, but which I'm sure is politically unacceptable to some members. Bill Return-Path: X-Sender: mail39718@alterdial.uu.net Date: Wed, 28 May 1997 22:40:29 -0700 To: "Kevin P. Tyson" From: "Robert E. Shelton" Subject: Re: The inheritance debate [was Re: terminology questions] Cc: Andrew Watson , Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch References: <199705281903.OAA04662@basie.cca.rockwell.com> At 09:57 PM 5/28/97 -0400, Kevin P. Tyson wrote: >>2) Should IDL be extended to represent object semantics in addition to >> describing interaction structure and datatypes? >> >> My answer - maybe. Another option would be to create separate >> description languages for semantics, to be used in parallel with IDL. >> This is attractive because there are all sorts of dimensions to >> "semantics" that we might want to represent (including pre- and post- >> conditions), and no one set is going to please everyone. > >The purist in me wants to extend IDL but there are good reasons not to do >so. One practical reason is that the vendors will be loath to extensively >modify their products without clear market pressure. Another is that IDL >is static and hence would have a hard time with dynamic systems like >Event-Condition-Action rules or Actor-based systems. Pardon if this has already been mentioned, as I've not read every item in this thread... An alternative to modifying IDL is under development by a group of BODTF RFP submitters. Those interested in representing semantics should speak with Cory Casanave. He can point to topical references, including a prototype complier for the IDL-based "component definition language" (CDL) that he and others have been working on. Net: CDL provides a set of IDL extensions for the BOF environment without requiring ORB-level modifications. The concepts should cross-apply to this discussion. Best, Robert Shelton **************************************************************** * Robert E. Shelton, President & CEO rshelton@openeng.com * * Open Engineering Inc. http://www.openeng.com * * 50 California, Suite 860 (v) 415-989-9050 * * San Francisco, CA 94111 (f) 415-989-9055 * **************************************************************** Return-Path: X-Sender: genillou@dimail.epfl.ch References: <199705281903.OAA04662@basie.cca.rockwell.com> Date: Thu, 29 May 1997 19:25:11 +0200 To: "Kevin P. Tyson" , Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org From: Guy Genilloud Subject: Re: The inheritance debate [the reference is 95-12-37] Cc: gwdaughe@cca.rockwell.com >At 15:03 -0400 5/28/97, Gary Daugherty wrote: >>To all, >> >>Personally I would like to see: >> >>1) IDL offer a means for specifying the semantics of services in a pre/post/ >> invariant style > >As would I. > >You might want to take a look at two documents on the OMG server. The >first is authored by Desmond D'Souza and Alan Wills. I don't have the >document number but it was posted in December 1995. It was a response the >OMG's RFI on Object Analysis and Design. In it they say, "We see the next >step as being the extension of IDL to cover behavioral specification >(rather than just signatures); and the definition of a common linguistic >basis between developer's support tools, so that they can exchange >information about component interfaces and architectures. We will refer to >this (future) language as IDL++." > Kevin, this is a reference I thought of including in my list of references about typing (and Emerald), but I forgot about it. I have started reading it a few weeks ago, and it seems to be very relevant to both the semantics representation and to the inheritance vs subtyping debate... I just checked: the reference on the OMG server is: 95-12-37: Icon Computing A&D RFI response [Desmond D'Souza and Alan Wills, Icon Computing] Response to the Analysis and Design Task Force's Request for Information. Available formats: PDF PostScript . Guy -------------------------------------------------------------------- Dr. Guy Genilloud Computer Engineering Department 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: Thu, 29 May 97 13:40:38 EDT From: edbark@cme.nist.gov (Ed Barkmeyer) To: ormsc@omg.org, orb_revision@omg.org Subject: Re: The inheritance debate [was Re: terminology questions] Andrew asks: > 1) Is representing object semantics at run time a Good Thing? > > My answer - Yes, quite clearly. Tell me what you mean by "object semantics" and I might be able to agree. In one sense the "representation of object semantics" is exactly the function provided by the Server, neither more nor less. (To paraphrase Carol, the asymptote of semantic representation is a programming language.) If you mean what Bill requests: > 1) We need to be able to precisely specify the particular operation we > wish to invoke ... > 2) We need to provide a mechanism to potential client to discern > whether or not a particular service supports a set of interfaces. ... > 3) We need to be able to export arbitrary multiple interfaces from a > service. ... That is, semantics = a) being able to identify a documented operation unambiguously and b) being able to determine whether a given Object instance supports that documented operation. Then my answer is Yes, quite clearly. If you mean what Gary asked for: > 1) IDL offer a means for specifying the semantics of services in a pre/post/ > invariant style or any such effort to characterize the operation instead of name it, I do not see an obvious use for this at runtime. > 2) Should IDL be extended to represent object semantics in addition to > describing interaction structure and datatypes? > > My answer - maybe. Another option would be to create separate > description languages for semantics, to be used in parallel with IDL. > This is attractive because there are all sorts of dimensions to > "semantics" that we might want to represent (including pre- and post- > conditions), and no one set is going to please everyone. I support Carol's carefully phrased response: > we will eventually want to add some minimal amount of semantics to IDL ... > that it be limited to what is necessary to ensure interoperability of > independently developed implementations when appropriate. In the debate thus far, we only see the need to "extend" IDL in ways that enhance "unique operation and interface labelling" and the ability to support "multiple and selective inheritance". (This is Bill's point.) For interface documentation purposes, IDL could be extended by many "semantics capturing features", but the ORB compiler would use none of that. Worse yet, I can envision improved operation labelling and improved multiple inheritance being special cases of some powerful semantic syntax addition, so that the ORB compiler would have to use AI techniques to deduce the useful information from the power syntax. (Think of troff or TeX vs. RTF.) Rather, I offer you the existing UML and other wonderful OA&D activities (as Andrew mentions), and the proposed CDL from the JBOF activity (as Robert mentions). I would strongly prefer that we do not create a third such project. Given these, what IDL needs is a "derives from " clause to hang on and , i.e. inclusion of extended semantics by reference. To Carol's point: > What does it mean to conform... are the semantic definitions part of the > specification? Absolutely. These would constitute (part of) the definition of the operation which we have contrived to "unambiguously identify". When the client uses the identifier, s/he must know what s/he is getting. Even so, I would agree that it becomes possible to write too strong a semantic requirement, so that unnecessary implementation rules are wired-in. But that only means we have to be very careful about how we write "normative" semantic specifications. Gary's precondition/postcondition form, for example, is usually implementation-free. > 3) Should we attempt to use IDL interface inheritance to represent > semantics? > > My answer - clearly no. Inheritance graphs are far too weak a > representational mechanism for this, and trying to use them to solve > part of the problem is no help. Let's leave inheritance to one side, > as a useful way of writing smaller IDL files, and address the semantics > description problem with a clean sheet. I agree. Clearly No. I just wish we hadn't called this "inheritance", if all we mean is "syntactic inclusion". And I believe chapter 3 will have to be revised to reflect the complete elimination of semantics, if that is what we really intend. (But to extend Carol's analogy, this will cause us to rake over still warm coals and we may expect some flames.) -Ed Return-Path: Date: Thu, 29 May 1997 12:44:58 -0500 From: Gary Daugherty To: kpt@enteng.com, andrew@omg.org Subject: Re: The inheritance debate [was Re: terminology questions] Cc: gwdaughe@cca.rockwell.com, Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch, gwdaughe@cca.rockwell.com Andrew, I agree that substituability can and should be defined independent of inheritance, the former is based on rules such as those proposed by Liskov & Wing or Dhara & Levenson while the latter is a mechanism for avoiding redundant respecification/allowing incremental specification. I, however, disagree re: the need to define the semantics of the inheritance mechanism. I feel it is imperative that we define what inheritance means in IDL (or in any specification language that uses inheritance for incremental specification). This definition of inheritance is then applied to "flatten" the associated specifications, to which we apply the test for behavioral subtyping. The same sort of approach applies to generic type parameters, i.e. we do substitution of actuals for formals according to the rules (semantics) of the specification language and compare the instantiated results. Or we both flatten and substitute, then compare the results. A specification language without inheritance and/or generic type parameters presumably would provide the equivalent of a "flattened" and "instantiated" specification to begin with so neither is needed to determine subsitutability. Both, however, should be well defined for any specification langauge that uses them (e.g. IDL with respect to inheritance). Furthermore, we should "do inheritance well" in IDL if we intend it to "support incremental specification well". This IMHO includes dealing with renaming and repeated inheritance well, i.e. putting control in the hands of the specifier of the subtype so that changes to ancestors are unnecessary to achieve the desired effect (in accordance with what Bertrand Meyer terms the open/closed principle). Rather than have you interpret this as a blanket endorsement of the Eiffel approach, I will point out that I disagree with their use of a covariant rule for subtype parameters and feel that their attempts "to patch things up" are less than satisfactory. I do feel, however, that they deal with renaming and repeated inheritance particularly well and set a good example that IDL could stand to follow. Best regards, Gary. P.S. I have read D'Souza's paper and like the general approach. We are also in contact with Dr. Leavens of Iowa State (mentioned in the paper with reference to Larch) and would like to see the development of tool support for an IDL with such semantic annotations. Re: whether such annotations should be added to IDL or whether a separate specification language should be defined, this is mostly political and logistical. Ignoring politics and logistics, I would favor an "improved" IDL with a mapping from the current definition to the new one, and an expected migration from the old to the new over some well defined period. A proliferation of competing interface specification languages seems to me to set no standard at all, be a political necessity or not. > From daemon Wed May 28 19:01:26 1997 > X-Sender: andrew@emerald.omg.org > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Date: Wed, 28 May 1997 19:59:45 -0400 > To: "Kevin P. Tyson" > From: Andrew Watson > Subject: Re: The inheritance debate [was Re: terminology questions] > Cc: Gary Daugherty , Mike_Spreitzer.PARC@xerox.com, > ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch > Content-Length: 2140 > > Kevin, > > You wrote: > > > >Personally I would like to see: > > > > > >1) IDL offer a means for specifying the semantics of services in a > > > pre/post/invariant style > > > > As would I. > > > > You might want to take a look at two documents on the OMG server. The > > first is authored by Desmond D'Souza and Alan Wills. I don't have the > > document number but it was posted in December 1995. It was a response the > > OMG's RFI on Object Analysis and Design. In it they say, "We see the next > > step as being the extension of IDL to cover behavioral specification > > (rather than just signatures); and the definition of a common linguistic > > basis between developer's support tools, so that they can exchange > > information about component interfaces and architectures. We will refer to > > this (future) language as IDL++." > > > > The second document is 95-12-12 and is titled, "Object Analysis and > > Design. The Eros group's RFI response" by Iain Houston and Alan Wills > > where they also call for behavior specifications in IDL. > > It seems to me that we now have 3 questions being considered simultaneously: > > 1) Is representing object semantics at run time a Good Thing? > > My answer - Yes, quite clearly. > > 2) Should IDL be extended to represent object semantics in addition to > describing interaction structure and datatypes? > > My answer - maybe. Another option would be to create separate > description languages for semantics, to be used in parallel with IDL. > This is attractive because there are all sorts of dimensions to > "semantics" that we might want to represent (including pre- and post- > conditions), and no one set is going to please everyone. > > 3) Should we attempt to use IDL interface inheritance to represent > semantics? > > My answer - clearly no. Inheritance graphs are far too weak a > representational mechanism for this, and trying to use them to solve > part of the problem is no help. Let's leave inheritance to one side, > as a useful way of writing smaller IDL files, and address the semantics > description problem with a clean sheet. > > Cheers, > > Andrew > > > > From daemon Wed May 28 19:36:40 1997 > X-Sender: andrew@emerald.omg.org > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset="us-ascii"> > Date: Wed, 28 May 1997 19:48:42 -0400 > To: Mike_Spreitzer.PARC@xerox.com > From: Andrew Watson > Subject: Re: The inheritance debate [was Re: terminology questions] > Cc: ormsc@omg.org, orb_revision@omg.org, Mike_Spreitzer.PARC@xerox.com > Content-Length: 1858 > > Mike, > > You wrote: > > > The first question for me, with my Ch1 revision hat on, is: what is the > > current design? It now seems clear to me that the current design has > > neither what Bill wants nor what Andrew wants. The fact that the GIOP > > uses only the simple operation names, and the fact the the current > > language in Ch1 vaguely suggests that operation identifiers are simple > > names, tells me that what Bill wants is not there now. > > Agreed. And I'd attach more weight to the concrete language in GIOP 1.1 > than the vague language in Chapter 1. > > > The fact that 1.2.5 "Interfaces" currently says "Interface > > inheritance provides the composition mechanism for permitting an object to > > support multiple interfaces" (this is awkward, IMHO, but somewhat answers > > the question at hand), and the fact that Andrew recognizes he's promoting > > a debatable position, tells me that what Andrew wants is not in the > > current design. Agreed? > > Not really. I know I'm promoting a debatable position because, er, people > keep debating it. The direct consequence of the relevant section in GIOP > 1.1 is to allow non-inheritance substitutability. The language in CORBA > chapter 1 always was ambiguous on this point, but if it was left up to me > it would now be made to align with GIOP 1.1 in stating unambiguously that > interface inheritance is not a necessary condition for substitutability. > > > The next question is: what can be changed by the ORB RTF for 2.1? It > > seems clear to me that neither what Bill wants nor what Andrew wants is a > > small enough change to do for 2.1. Agreed? > > Again I'd beg to differ. Fixing Chapter 1 to align with GIOP 1.1 just > corrects an ambiguity in Chpter 1. Adding about two sentences ought to do > it. GIOP wouldn't need changing at all. > > Cheers, > > Andrew > > > Return-Path: From: Mike_Spreitzer.PARC@xerox.com X-NS-Transport-ID: 0000AA006EEAC85C3731 Date: Thu, 29 May 1997 12:13:37 PDT Subject: The inheritance debate To: orb_revision@omg.org cc: Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org I've clearly stepped on a land-mine here. And there's clearly no time to resolve this for 2.1. I'm submitting a few minor changes for 2.1 to Paul Rabin today. I'm going to try to leave this issue untouched. I'm going to try to simply preserve the ambiguity in the existing language. This will be slightly challenging because I'm trying to eliminate the (possible) redundancy between the terms "object type" and "interface type", which both appear in Ch 1. It's ambiguous whether the extent of an interface type is object references or objects. By eliminating the term "interface type", this doesn't have to be cleared up. The ambiguity wrt the extent of an interface type is not a necessary ingredient to the ambiguity wrt whether subtyping implies inheritance. Return-Path: From: Cory Casanave To: Andrew Watson , "Kevin P. Tyson" , "'Carol Burt'" Cc: Gary Daugherty , "Mike_Spreitzer.PARC@xerox.com" , "ormsc@omg.org" , "orb_revision@omg.org" , "guy.genilloud@di.epfl.ch" Subject: RE: The inheritance debate [was Re: terminology questions] Date: Thu, 29 May 1997 19:50:08 -0400 Carol, Since you can't resist any longer... IF I may be so bold as to "name that line" between semantics you do and don't want to specify at the level we are talking about. It is "specification semantics" Vs. "implementation semantics". Specification semantics are those that another component (object, whatever) may count on in it's use of or interaction with another object. Implementation semantics is everything else. Note that this definition is very viewpoint sensitive. What a user may count on when interacting with a web page is quite different from what the web server will count on (stuff like it being CGI). So we should qualify the viewpoint. In domain specifications we are concerned with the domain viewpoint - the domain semantics. It is also important for these semantics to be partitioned from the other viewpoints, to allow for independent specification and evolution. So, we want specification semantics for at least the domain viewpoint independent from the semantics of other viewpoints. For ODP Bigots (Kevin), I think the domain viewpoint includes ODP: Enterprise and Information viewpoints. Test for domain specification semantics: Sam (Owner of object B) meets Sam (Owner of object B) by the jolt-cola machine. Sam asks Sue - Sue, what does A do when ???, Sue responds with a something useful - like "42". Sam now knows what B should do, happy (he has Jolt-cola and a new fun fact), he now implements according to the new fact. If you can fit the "semantic" in ??? it is specification semantics. Why? If it wasn't, it would be Sue's job to say "don't count on that, it may change". If an answer is appropriate it should be IN THE SPECIFICATION, not passed via the jolt-cola machine. Consider that 2 years later, both Sam and Sue have moved on. Frank, ( A new owner-A) looks at the code and thinks, why did that idiot do that, I will change 42 to -1. Guess who's program is dead? How hard will it be to find? Rule: You can only count in semantics in the specification. Assumption: A component should be used by others, this will only happen if it is easy to (re) use. Corollary: You have to specify enough to make your component easy to use. Cory ---------- From: Carol Burt[SMTP:cburt@2ab.com] Sent: Wednesday, May 28, 1997 9:50 PM To: Andrew Watson; Kevin P. Tyson Cc: Gary Daugherty; Mike_Spreitzer.PARC@xerox.com; ormsc@omg.org; orb_revision@omg.org; guy.genilloud@di.epfl.ch Subject: Re: The inheritance debate [was Re: terminology questions] Hi, Well I can't resist any longer... In reply to Kevin's message, Andrew wrote: >2) Should IDL be extended to represent object semantics in addition to > describing interaction structure and datatypes? > > My answer - maybe. Another option would be to create separate > description languages for semantics, to be used in parallel with IDL. > This is attractive because there are all sorts of dimensions to > "semantics" that we might want to represent (including pre- and post- > conditions), and no one set is going to please everyone. I agree. First let me say that I think we will eventually want to add some minimal amount of semantics to IDL. HOWEVER, my bias is that it be limited to what is necessary to ensure interoperability of independently developed implementations when appropriate(ie, we want to federate Traders, Naming Services, Patient Identification Services). It also remains to be seen what, if anything, will happen at the IDL level for a Component Model which obviously must be "well behaved". In some sense, it is the line between interface and implementation which is being discussed. It could be considered a feature that, in different environments, I can implement the same IDL with diverse semantics.... It is clearly necessary to understand the semantics of an implementation in order to use it... but it is clearly not a reasonable goal to fully define semantics in IDL. If you could, you'd have defined a programming language and you could merely generate the implementation for your favorite language and compile it. It's hard enough to design interfaces "by committee", imagine designing implementation that way. This has been my concern about "some of" (not your's Kevin) the semantic discussions I've been involved in.... they tend to frighten me as they wander beyond the practical into academia. Andrews suggestion of a separate descriptive language for semantics is very attractive. The question then becomes: What do we adopt as technology? What does it mean to conform... are the semantic definitions part of the specification? I'm biased toward adopting IDL which has the minimal extensions I mentioned above.... if for no other reason than I think agreeing on "semantics" in a large diverse organization with many different viewpoints (ODP pun intended) isn't a goal we are likely attain. > >3) Should we attempt to use IDL interface inheritance to represent > semantics? > > My answer - clearly no. Inheritance graphs are far too weak a > representational mechanism for this, and trying to use them to solve > part of the problem is no help. Let's leave inheritance to one side, > as a useful way of writing smaller IDL files, and address the semantics > description problem with a clean sheet. > If we wanted to do this, the (non-existant) typing system debate should be resolved first :-) Debate has raged on this without resolution - or with the resolution that there is no typing system - for as long as I can remember (the ember's never go out and the flames erupt from time to time as they have recently). I've tended to agree with Andrew that subtyping and inheritance should be distinct... which obviously means that there are no semantics implied by the inheritance graph today, nor should there be. Carol ____________________________________________________________________ Carol Burt cburt@2ab.com 2AB, INC. 205-250-6392 2AB specializes in Integration Architecture using CORBA technology! Return-Path: X-Sender: kpt@pop.galaxy.net (Unverified) Date: Fri, 30 May 1997 11:25:32 -0400 To: Gary Daugherty , andrew@omg.org From: "Kevin P. Tyson" Subject: CORBA/LARCH Refernce [was Re: The inheritance debate [was Re: terminology questions]] Cc: gwdaughe@cca.rockwell.com, Mike_Spreitzer.PARC@xerox.com, ormsc@omg.org, orb_revision@omg.org, guy.genilloud@di.epfl.ch Gary, >... >P.S. I have read D'Souza's paper and like the general approach. We are also >in contact with Dr. Leavens of Iowa State (mentioned in the paper with >reference >to Larch) and would like to see the development of tool support for an IDL >with such semantic annotations. More information on the work done to date on Larch and CORBA may be obtained from http://www.cs.iastate.edu/~leavens/main.html#LarchCORBA Best regards, Kevin -- Kevin P. Tyson Enterprise Engineering Associates, 18 Foxcroft Drive, Marlboro NJ 07746-1664 http://www.enteng.com/ mailto:kpt@enteng.com voice:908.972.3421 fax:908.972.9349 page:800.279.3150 pin:99627 Return-Path: X-Sender: kpt@pop.galaxy.net Date: Sun, 1 Jun 1997 17:20:37 -0400 To: Cory Casanave , Andrew Watson , "'Carol Burt'" From: "Kevin P. Tyson" Subject: RE: The inheritance debate [was Re: terminology questions] Cc: Gary Daugherty , "Mike_Spreitzer.PARC@xerox.com" , "ormsc@omg.org" , "orb_revision@omg.org" , "guy.genilloud@di.epfl.ch" Cory, >IF I may be so bold as to "name that line" between semantics you do and >don't want to specify at the level we are talking about. It is >"specification semantics" Vs. "implementation semantics". Specification >semantics are those that another component (object, whatever) may count on >in it's use of or interaction with another object. > >Implementation semantics is everything else. Naming the line is not sufficient. We have to state precisely how to relate "specification semantics" to "implementation semantics". This is something we all do intuitively. All of us know what the arithmetic statement "1 / 3" means. We also know that the C statement "(int) 1 / (int) 3" means something similar but different. The former is "specification semantics" the latter "implementation semantics." Tony Hoare has described the general technique of specifying the relationship between these different sorts of specifications (see ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Tony.Hoare/mathmodl.ps). He calls it the linking invariant. >Note that this definition is very viewpoint sensitive. What a user may >count on when interacting with a web page is quite different from what the >web server will count on (stuff like it being CGI). So we should qualify >the viewpoint. In domain specifications we are concerned with the domain >viewpoint - the domain semantics. It is also important for these >semantics to be partitioned from the other viewpoints, to allow for >independent specification and evolution. > >So, we want specification semantics for at least the domain viewpoint >independent from the semantics of other viewpoints. For ODP Bigots >(Kevin), I think the domain viewpoint includes ODP: Enterprise and >Information viewpoints. The congregation will please turn to Part 3 of the Good Book, section 4.1.1, where we find the following: 4.1.1.1 Enterprise viewpoint: A viewpoint on an ODP system and its environment that focuses on the purpose, scope and policies for that system. 4.1.1.2 Information viewpoint: A viewpoint on an ODP system and its environment that focuses on the semantics of information and information processing. Given these definitions, I'm not sure what you mean by domain viewpoint. For example, the trader specification includes both enterprise and information specifications. Do they comprise the domain viewpoint on the trader? I think we need an intensional definition of domain. I wonder if the separation of concerns you are trying to achieve is closer to Gregor Kiczales' notion of Aspect Oriented Programming (See http://www.parc.xerox.com/spl/projects/aop/default.shtml )? This work extends the concepts of modularity and separation of concerns into "aspects." Quoting from the web page, "An aspect is a self-contained subprogram that describes a global property of the program. Each application domain might have a different set of aspects, such as synchronization and distribution aspects for Client/Server applications or matrix representation aspects for scientific applications. Aspects are automatically combined into an executable program image by a new kind . The executable program image is like a tapestry where each Aspect is a single kind of thread. Aspect-Oriented Programming allows the tapestry to be woven automatically, while current programming paradigms require programmers to sew the entire tapestry by hand." From previous conversations I know that Gregor does not see aspects as analogous to RM-ODP viewpoints. I wonder if Mike Spreitzer is sufficiently familiar about both to comment? Best regards, Kevin -- Kevin P. Tyson Enterprise Engineering Associates, 18 Foxcroft Drive, Marlboro NJ 07746-1664 http://www.enteng.com/ mailto:kpt@enteng.com voice:908.972.3421 fax:908.972.9349 page:800.279.3150 pin:99627 Return-Path: X-Sender: kpt@pop.galaxy.net Date: Sun, 1 Jun 1997 17:20:37 -0400 To: Cory Casanave , Andrew Watson , "'Carol Burt'" From: "Kevin P. Tyson" Subject: RE: The inheritance debate [was Re: terminology questions] Cc: Gary Daugherty , "Mike_Spreitzer.PARC@xerox.com" , "ormsc@omg.org" , "orb_revision@omg.org" , "guy.genilloud@di.epfl.ch" Cory, >IF I may be so bold as to "name that line" between semantics you do and >don't want to specify at the level we are talking about. It is >"specification semantics" Vs. "implementation semantics". Specification >semantics are those that another component (object, whatever) may count on >in it's use of or interaction with another object. > >Implementation semantics is everything else. Naming the line is not sufficient. We have to state precisely how to relate "specification semantics" to "implementation semantics". This is something we all do intuitively. All of us know what the arithmetic statement "1 / 3" means. We also know that the C statement "(int) 1 / (int) 3" means something similar but different. The former is "specification semantics" the latter "implementation semantics." Tony Hoare has described the general technique of specifying the relationship between these different sorts of specifications (see ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Tony.Hoare/mathmodl.ps). He calls it the linking invariant. >Note that this definition is very viewpoint sensitive. What a user may >count on when interacting with a web page is quite different from what the >web server will count on (stuff like it being CGI). So we should qualify >the viewpoint. In domain specifications we are concerned with the domain >viewpoint - the domain semantics. It is also important for these >semantics to be partitioned from the other viewpoints, to allow for >independent specification and evolution. > >So, we want specification semantics for at least the domain viewpoint >independent from the semantics of other viewpoints. For ODP Bigots >(Kevin), I think the domain viewpoint includes ODP: Enterprise and >Information viewpoints. The congregation will please turn to Part 3 of the Good Book, section 4.1.1, where we find the following: 4.1.1.1 Enterprise viewpoint: A viewpoint on an ODP system and its environment that focuses on the purpose, scope and policies for that system. 4.1.1.2 Information viewpoint: A viewpoint on an ODP system and its environment that focuses on the semantics of information and information processing. Given these definitions, I'm not sure what you mean by domain viewpoint. For example, the trader specification includes both enterprise and information specifications. Do they comprise the domain viewpoint on the trader? I think we need an intensional definition of domain. I wonder if the separation of concerns you are trying to achieve is closer to Gregor Kiczales' notion of Aspect Oriented Programming (See http://www.parc.xerox.com/spl/projects/aop/default.shtml )? This work extends the concepts of modularity and separation of concerns into "aspects." Quoting from the web page, "An aspect is a self-contained subprogram that describes a global property of the program. Each application domain might have a different set of aspects, such as synchronization and distribution aspects for Client/Server applications or matrix representation aspects for scientific applications. Aspects are automatically combined into an executable program image by a new kind . The executable program image is like a tapestry where each Aspect is a single kind of thread. Aspect-Oriented Programming allows the tapestry to be woven automatically, while current programming paradigms require programmers to sew the entire tapestry by hand." From previous conversations I know that Gregor does not see aspects as analogous to RM-ODP viewpoints. I wonder if Mike Spreitzer is sufficiently familiar about both to comment? Best regards, Kevin -- Kevin P. Tyson Enterprise Engineering Associates, 18 Foxcroft Drive, Marlboro NJ 07746-1664 http://www.enteng.com/ mailto:kpt@enteng.com voice:908.972.3421 fax:908.972.9349 page:800.279.3150 pin:99627 of compiler called an Aspect Weaver Return-Path: From: Cory Casanave To: Cory Casanave , Andrew Watson , "'Carol Burt'" , "'Kevin P. Tyson'" Cc: Gary Daugherty , "Mike_Spreitzer.PARC@xerox.com" , "ormsc@omg.org" , "orb_revision@omg.org" , "guy.genilloud@di.epfl.ch" , "'bodtf@omg.org'" Subject: RE: Specification Semantics [Was: The inheritance debate [was Re: terminology questions]] Date: Mon, 2 Jun 1997 11:20:34 -0400 Kevin, See in-line. ---------- From: Kevin P. Tyson[SMTP:kpt@enteng.com] Sent: Sunday, June 01, 1997 5:21 PM To: Cory Casanave; Andrew Watson; 'Carol Burt' Cc: Gary Daugherty; Mike_Spreitzer.PARC@xerox.com; ormsc@omg.org; orb_revision@omg.org; guy.genilloud@di.epfl.ch Subject: RE: The inheritance debate [was Re: terminology questions] Cory, >IF I may be so bold as to "name that line" between semantics you do and >don't want to specify at the level we are talking about. It is >"specification semantics" Vs. "implementation semantics". Specification >semantics are those that another component (object, whatever) may count on >in it's use of or interaction with another object. > >Implementation semantics is everything else. Naming the line is not sufficient. We have to state precisely how to relate "specification semantics" to "implementation semantics". This is something we all do intuitively. All of us know what the arithmetic statement "1 / 3" means. We also know that the C statement "(int) 1 / (int) 3" means something similar but different. The former is "specification semantics" the latter "implementation semantics." Tony Hoare has described the general technique of specifying the relationship between these different sorts of specifications (see ftp://ftp.comlab.ox.ac.uk/pub/Documents/techpapers/Tony.Hoare/mathmodl.ps). He calls it the linking invariant. [Cory] I certainly agree that identification of the "domain" specification semantics line is not sufficient for a complete system specification. It is the aggregation of all viewpoint specifications that must comprise a fully realized information system or component of it. However, the domain specification semantics may be sufficient as the concern of a domain focused group, such as an OMG DTC or an application designer. It is the exclusion of inappropriate viewpoints that gives such a specification long-lived and general usefulness. I was not able to convert the referenced paper (to PDF) but I do agree that any work on improving the linking between viewpoints is valuable. In our model the type system is the unification point. >Note that this definition is very viewpoint sensitive. What a user may >count on when interacting with a web page is quite different from what the >web server will count on (stuff like it being CGI). So we should qualify >the viewpoint. In domain specifications we are concerned with the domain >viewpoint - the domain semantics. It is also important for these >semantics to be partitioned from the other viewpoints, to allow for >independent specification and evolution. > >So, we want specification semantics for at least the domain viewpoint >independent from the semantics of other viewpoints. For ODP Bigots >(Kevin), I think the domain viewpoint includes ODP: Enterprise and >Information viewpoints. The congregation will please turn to Part 3 of the Good Book, section 4.1.1, where we find the following: 4.1.1.1 Enterprise viewpoint: A viewpoint on an ODP system and its environment that focuses on the purpose, scope and policies for that system. 4.1.1.2 Information viewpoint: A viewpoint on an ODP system and its environment that focuses on the semantics of information and information processing. Given these definitions, I'm not sure what you mean by domain viewpoint. For example, the trader specification includes both enterprise and information specifications. Do they comprise the domain viewpoint on the trader? I think we need an intensional definition of domain. [Cory] I am using domain as nothing more or less than an "area of concern" with the understanding that areas' of concern intersect and overlap. This seems to encompass the definitions above (But, feel free to propose another word). I wonder if the separation of concerns you are trying to achieve is closer to Gregor Kiczales' notion of Aspect Oriented Programming (See http://www.parc.xerox.com/spl/projects/aop/default.shtml )? This work extends the concepts of modularity and separation of concerns into "aspects." Quoting from the web page, "An aspect is a self-contained subprogram that describes a global property of the program. Each application domain might have a different set of aspects, such as synchronization and distribution aspects for Client/Server applications or matrix representation aspects for scientific applications. Aspects are automatically combined into an executable program image by a new kind of compiler called an Aspect Weaver?. The executable program image is like a tapestry where each Aspect is a single kind of thread. Aspect-Oriented Programming allows the tapestry to be woven automatically, while current programming paradigms require programmers to sew the entire tapestry by hand." [Cory] Yes, it looks like the intentions may be quite similar at a couple of levels. Both at the level of separating the "domain" specification from the technology specification and in separating area's of concern within a domain specification. An early word for what we have been calling "role" was "aspect" but we changed it to fit with what the modeling folks were using (well, some of them, like OORAM) . Components may be a pre structured way to achieve some of the aspects of aspects. Aspects look like they may be one step past pre-structured components in that they can assemble aspects that may have not been designed to be assembled. A particular [current] component can only "plug into" the frameworks (aspects?, viewpoints?) it was designed for. >From previous conversations I know that Gregor does not see aspects as analogous to RM-ODP viewpoints. I wonder if Mike Spreitzer is sufficiently familiar about both to comment? [Cory] I have to admit that I fail to get a lot out of the RM-ODP viewpoints. They don't seem to quite partition the problem in a way I can use. The idea of partitioning along some lines somewhat like these is good, but both the boxes and lines may still need some work. I'm not even sure that the number or definitions of the viewpoint partitions is "fixed", it may depend on the viewpoint (how 's that for circular?). Best regards, Kevin [Cory] Regards, Cory -- Kevin P. Tyson Enterprise Engineering Associates, 18 Foxcroft Drive, Marlboro NJ 07746-1664 http://www.enteng.com/ mailto:kpt@enteng.com voice:908.972.3421 fax:908.972.9349 page:800.279.3150 pin:99627