Issue 66: Whether unions carry exact discriminant information (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: It is uncertain whether or not the explicit value used to discriminate between various arms of a union is information which is required to be supported. Resolution: resolved, close issue Revised Text: Value of aunion type includes the exact value of the discriminator. Move this requirement to Chapter 1, since it is a requirement on the type model, not on IDL Actions taken: August 5, 1996: Received issue March 25, 1997: Closed issue Discussion: End of Annotations:===== From geoff Mon Aug 5 11:57:02 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13234; Mon, 5 Aug 1996 11:57:02 -0400 Date: Mon, 5 Aug 1996 11:57:02 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051557.AA13234@amethyst.omg.org> To: issue-logger@omg.org Subject: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Wed, 31 Jul 1996 14:22:40 PDT Sender: Bill Janssen From: Bill Janssen To: ab@omg.org, issues@omg.org, orbos@omg.org Subject: question about whether unions carry exact discriminant information In reading the Smalltalk mapping, I find the following (in the overview): ``Because of the dynamic nature of Smalltalk, the mapping of the any and union types is such that an explicit mapping is unnecessary. Instead, the value of the any and union types can be passed directly. In the case of the any type, the Smalltalk mapping will derive a TypeCode which can be used to represent the value. In the case of the union type, the Smalltalk mapping will derive a discriminator which can be used to represent the value.'' Since this mapping has been debated and accepted by the OMG, this says to me that OMG IDL union discrimination information is not required to be preserved by a conforming ORB or CORBAservice, since that ORB or service may be written in Smalltalk; that is, the explicit value used to discriminate between various arms of the union is information which a conforming implementation is free to discard. In addition, if two arms have the same type, they can be combined or interchanged. In particular, this information need not be preserved by any communication protocol, including the IIOP. Is my inference correct? It would be a significantly useful reduction in the implementation complexity for CORBA unions, if so. Bill From geoff Mon Aug 5 11:58:39 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13258; Mon, 5 Aug 1996 11:58:39 -0400 Date: Mon, 5 Aug 1996 11:58:39 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051558.AA13258@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Wed, 31 Jul 1996 15:38:27 -0700 From: kpersson@parcplace.com (Kenneth Persson) To: janssen@parc.xerox.com Subject: Re: question about whether unions carry exact discriminant information Cc: ab@omg.org, issues@omg.org, orbos@omg.org X-Sun-Charset: US-ASCII Bill, Smalltalk itself keeps more runtime information than e.g C and C++. In this case meaning it doesn't need the programmer to manage the union discrimination information. What goes over the wire is still the same. Distributed Smalltalk from ParcPlace let the user take control and use the explicit binding if she wants to. I see no reasons to do that, just another level of meta-info, but the option is there for an implementor. Again what goes over the (IIOP) wire is the same. /Kenneth > From janssen@parc.xerox.com Wed Jul 31 14:52:06 1996 > In reading the Smalltalk mapping, I find the following (in the overview): > > ``Because of the dynamic nature of Smalltalk, the mapping of the any and > union types is such that an explicit mapping is unnecessary. Instead, > the value of the any and union types can be passed directly. In the case > of the any type, the Smalltalk mapping will derive a TypeCode which can > be used to represent the value. In the case of the union type, the > Smalltalk mapping will derive a discriminator which can be used to > represent the value.'' > > Since this mapping has been debated and accepted by the OMG, this says > to me that OMG IDL union discrimination information is not required to > be preserved by a conforming ORB or CORBAservice, since that ORB or > service may be written in Smalltalk; that is, the explicit value used to > discriminate between various arms of the union is information which a > conforming implementation is free to discard. In addition, if two arms > have the same type, they can be combined or interchanged. In > particular, this information need not be preserved by any communication > protocol, including the IIOP. > > Is my inference correct? It would be a significantly useful reduction > in the implementation complexity for CORBA unions, if so. > > Bill > > -- Kenneth Persson, kpersson@parcplace.com, (408)773-7462 Fax(408)481-0224 ParcPlace-Digitalk, Inc. 999 E. Arques Avenue, Sunnyvale, CA 95086-4593 "Install with this side down" From geoff Mon Aug 5 12:00:52 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13297; Mon, 5 Aug 1996 12:00:52 -0400 Date: Mon, 5 Aug 1996 12:00:52 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051600.AA13297@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Wed, 31 Jul 1996 17:28:37 -0700 From: kpersson@parcplace.com (Kenneth Persson) To: ab@omg.org, issues@omg.org, orbos@omg.org Subject: Re: question about whether unions carry exact discriminant information Cc: janssen@parc.xerox.com, kpersson@parcplace.com Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Md5: gs7fsVzUjqdtMMkXJUogvw== A smalltalk implementor facing the following union would need to go explicit to garantee the invariant. Fortunately for users of the Smalltalk ORBs, those multi-mapped unions are not very common. So she can use the implicit binding most of the time. But it seems like a Smalltalk ORB vendor need to support both implicit and explicit binding for unions. DST do! ---- example from Bill --- Well, the question is about the abstract mapping, not about your implementation, but even so, how would you answer the following question: Suppose we have the IDL: union foo switch (long) { case -1: case 13: case 47: long a; case 9: case 10: case 498: long b: case 11: float c; default: long d; }; (Hope I got that syntax right!). If a Distributed Smalltalk ORB received a "foo" value from somewhere, passed it through several Smalltalk interfaces, and then wrote it out again, would the marshalled form guarantee to use the same discriminant value on output that it received on input? From geoff Mon Aug 5 12:00:58 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13302; Mon, 5 Aug 1996 12:00:58 -0400 Date: Mon, 5 Aug 1996 12:00:58 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051600.AA13302@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Wed, 31 Jul 1996 17:42:01 PDT Sender: Bill Janssen From: Bill Janssen To: ab@omg.org, issues@omg.org, orbos@omg.org, kpersson@parcplace.com (Kenneth Persson) Subject: Re: question about whether unions carry exact discriminant information Cc: janssen@parc.xerox.com, kpersson@parcplace.com In-Reply-To: <199608010028.RAA03979@rigel.PPS> Excerpts from direct: 31-Jul-96 Re: question about whether .. Kenneth Persson@parcplac (1011*) > But it seems like a > Smalltalk ORB vendor need to support both implicit and explicit > binding for unions. Not if they only need to conform to the spec (whatever implicit and explicit binding is). Bill From geoff Mon Aug 5 12:01:04 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13307; Mon, 5 Aug 1996 12:01:04 -0400 Date: Mon, 5 Aug 1996 12:01:04 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051601.AA13307@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Wed, 31 Jul 1996 18:24:36 PDT Sender: Bill Janssen From: Bill Janssen To: orbos@omg.org Subject: Re: question about whether unions carry exact discriminant information In-Reply-To: [ The Smalltalk mapping does not guarantee to preserve all of the information that an IDL union or any type can be invested with. ] I see three possible resolutions: 1) ``Fix'' the Smalltalk mapping by requiring the Smalltalk representation of a union value to carry the explicit discriminant value, its exact IDL type (possibly implicitly), and the actual value. This is an ugly un-Smalltalkish way of doing things, but then OMG IDL unions are ugly to start with. We have done this with our ILU Python and Common Lisp mappings, much to the disgust of Python and Common Lisp programmers. 2) Specify that CORBA services of all sorts may not be implemented with Smalltalk ORBs (or ORBs using other `partial' or ambiguous mappings). This seems an unnecessary restriction on Smalltalk programmers, but has the nice advantage of making clear to language mapping designers that information is important and needs to be preserved. 3) Remove some of the ugly and pointless complexity of the OMG IDL union type -- fix unions by removing the tramp ideas from C/C++ that clutter them. This would be my favorite resolution. I'd re-write the OMG IDL union spec to say that (1) only enumeration types are possible as union discriminant types; (2) only one case value is allowed per union arm; (3) no two arms of a union may have the same type; (4) no default arm of the union type may be specified. This provides an unambiguous mapping for dynamically typed languages like Common Lisp, Smalltalk, and Python, without loss of any functionality (the functionality no longer in the union can be easily regained by wrapping a union type in a struct). Bill From geoff Mon Aug 5 12:15:03 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13498; Mon, 5 Aug 1996 12:15:03 -0400 Date: Mon, 5 Aug 1996 12:15:03 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051615.AA13498@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 From: Michi Henning Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information To: janssen@parc.xerox.com (Bill Janssen) Date: Fri, 2 Aug 1996 01:15:22 +1000 (EST) Cc: orbos@omg.org In-Reply-To: <0m00RIEB0KGW1ZHF9F@holmes.parc.xerox.com> from "Bill Janssen" at Jul 31, 96 06:24:36 pm Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Bill writes: > > 3) Remove some of the ugly and pointless complexity of the OMG IDL > union type -- fix unions by removing the tramp ideas from C/C++ that > clutter them. This would be my favorite resolution. I agree. However, removing something from the standard will break some existing code - not exactly polite. > I'd re-write the > OMG IDL union spec to say that (1) only enumeration types are possible > as union discriminant types; This strikes me as a very harsh restriction - allowing integral types as it stands now seems fine. Why restrict it to only allow enumerations? > (3) no two arms of a union may have the same type; I agree, it does not make sense to have two union members with the same type. However, I don't think this should be prohibited. Consider: In one IDL file: typedef short temperature_t; In another IDL file: typedef short offset_t; In a third IDL file: #include "first.idl" #include "second.idl" union some_name switch (long) { case 0: temperature_t temperature; case 1: offset_t offset; }; The problem I see is that in this case, having the same type for two different union members can actually make sense. Even though both temperature_t and offset_t are both of type short, conceptually (at the application level), they are different types. Also, if a union cannot have two members with the same type, it would be very easy to accidentally break specifications. Consider a case where Developer 2 re-uses the specification of Developer 1 by #including it, and Developer 2 uses a union member with a type defined by Developer 1. This is a correct specification. If now Developer 1 changes a single typedef, all of a sudden the specification of Developer 2 is broken. Not very nice... > (2) only one case value is allowed per > union arm; (4) no default arm of the union type may be specified. I completely agree. I have never found a need for these (mis)features in many years of programming. When I teach CORBA to my students, I recommend that they do not use them. If you look at the C++ mapping, all the complexity and strange rules about the use of _d() and _default() arise from those features. Remove the features, and you end up with a much cleaner and simpler mapping, and fewer implementation headaches. 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 From geoff Mon Aug 5 12:17:14 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13538; Mon, 5 Aug 1996 12:17:14 -0400 Date: Mon, 5 Aug 1996 12:17:14 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051617.AA13538@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Thu, 1 Aug 1996 13:37:46 PDT Sender: Bill Janssen From: Bill Janssen To: janssen@parc.xerox.com (Bill Janssen), Michi Henning Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information Cc: orbos@omg.org In-Reply-To: <199608011515.BAA04212@azure.dstc.edu.au> I believe Ken Persson's response was most to the point. For Smalltalk, the explicit mapping should be used for every service which may potentially communicate with another ORB. The implicit mapping (natural as it is) should be deprecated. I still feel that IDL unions should be cleaned up. Bill From geoff Mon Aug 5 12:17:26 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13553; Mon, 5 Aug 1996 12:17:26 -0400 Date: Mon, 5 Aug 1996 12:17:26 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051617.AA13553@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 X-Sender: genillou@dimail.epfl.ch Mime-Version: 1.0 Date: Fri, 2 Aug 1996 10:27:36 +0100 To: Bill Janssen , Michi Henning From: Guy.Genilloud@di.epfl.ch (Guy Genilloud) Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information Cc: orbos@omg.org At 1:37 PM 8/1/96, Bill Janssen writes: >I believe Ken Persson's response was most to the point. For Smalltalk, >the explicit mapping should be used for every service which may >potentially communicate with another ORB. The implicit mapping (natural >as it is) should be deprecated. > >I still feel that IDL unions should be cleaned up. > The best possibility to achieve what you say will probably to invent a new type, say IDL variant record, and to deprecate IDL unions (forbid their use in all common services, etc.). Guy ----------------------------------------------------------------------------- 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 ---------------------------------------------------------------------------- -- From geoff Mon Aug 5 12:17:38 1996 Received: by amethyst.omg.org (5.4R2.01/1.34) id AA13562; Mon, 5 Aug 1996 12:17:38 -0400 Date: Mon, 5 Aug 1996 12:17:38 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608051617.AA13562@amethyst.omg.org> To: issue-logger@omg.org Subject: Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 From: A.J.Eaton@nortel.co.uk Date: Fri, 2 Aug 96 11:20:34 BST To: janssen@parc.xerox.com Subject: Re: question about whether unions carry exact discriminant information Cc: orbos@omg.org > I believe Ken Persson's response was most to the point. For Smalltalk, > the explicit mapping should be used for every service which may > potentially communicate with another ORB. The implicit mapping (natural > as it is) should be deprecated. > > I still feel that IDL unions should be cleaned up. Having implemented a Smalltalk ORB that NEEDED to inter-work with both a C and a C++ ORB, both unions and anys have caused problems. We have avoided the union problem by providing ONLY the explicit mapping, but CORBA anys are proving to be more problematical. The problems are centered around constructing a correct/valid CORBA TypeCode to ba passed as part of a CORBA any. In Smalltalk, certain information is just not available: o structure/union names o a complete set of enumeration ids o actual types of Integers, including those within unions structures, sequences and arrays and other information cannot be derived accurately: o structure member ordering as defined in IDL Some of this can be handled using a best guess approach, but other information (struct/union names, enum ids) must just be omitted. We are currently looking at providing the option of allowing the application programmer to specify a TypeCode for a type to allow it to be communicated to C and C++ ORBs accurately: asCORBAAny: anyValue typeCode: aTypeCode This will require the generation of Smalltalk TypeCodes from IDL type definitions and will obviously be non-conformant to the Smalltalk binding. As the Smalltalk language bindings stand, there are real problems when trying to inter-work with C and C++ ORBs. The authors of the Smalltalk binding seem to have only been concerned with constructing Smalltalk only systems. Thanks. Anthony Eaton. Senior Research Engineer, Distributed Systems and Services. -- Email: A.J.Eaton@bnr.co.uk Address: Nortel Technology, London Road, Tel: +44 (0)1279 402742 Harlow, Essex, CM17 9NA, Fax: +44 (0)1279 451866 United Kingdom From geoff Tue Aug 13 10:27:45 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA09357; Tue, 13 Aug 1996 10:27:45 -0400 Date: Tue, 13 Aug 1996 10:27:45 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608131427.AA09357@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: Re: [Issue 66] question about whether unions carry exact discriminant information X-Omg-Issue: 66 From: Tim.Roberts.3202975@nortel.co.uk Date: Tue, 6 Aug 96 09:39:17 BST To: geoff@omg.org Subject: Re: [Issue 66] question about whether unions carry exact discriminant information Geoff, I hope that we can attach additional information with this issue. Specifically, it is worth noting that, in contradiction to Bill's message, the explicit mapping is the only one you can use when communicating to C/C++ components and even then it hasn't got enough information for the any type. As a result, this information must be carried on the wire and, therefore, especially in IIOP. There have been a number of folow-up messages which raise this point, notably Anthony Eaton from Nortel and a reply by Bill to a Ken Persson message which Bill agrees that the explicit binding should be used where communication with another ORB is possible. My concern here is that these problems have arisen as a result of the language bindings being developed by Smalltalk people to be best for Smalltalk without really considering the needs of multi-language systems. Thus the Smalltalk revision task force should be asked to consider this interoperability explicitly hence the addendum to the issue. Tim Roberts Nortel From geoff Tue Aug 13 13:24:32 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA11947; Tue, 13 Aug 1996 13:24:32 -0400 Date: Tue, 13 Aug 1996 13:24:32 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608131724.AA11947@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Mon, 12 Aug 1996 14:03:11 -0700 From: kpersson@parcplace.com (Kenneth Persson) To: janssen@parc.xerox.com, michi@dstc.edu.au Subject: Re: [omg-ostf] Re: question about whether unions carry exact discriminant information Cc: orbos@omg.org Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Md5: JstDdE5jhPe51Oap9a2PIw== >=20 > I believe Ken Persson's response was most to the point. For = Smalltalk, > the explicit mapping should be used for every service which may > potentially communicate with another ORB. The implicit mapping = (natural > as it is) should be deprecated. Hmm. The explicit mapping need only be used in strange cases like the = one you provided. It is then given from the IDL and the programmer has to=20 recognize it. So again it is an implementation decision that has nothing to do with interoperation with other ORBs or not. The implicit binding is so much nicer and useful for 99.9% of all cases. > I still feel that IDL unions should be cleaned up. I still think IDL unions can be a sign of bad interface design ;-) /Kenneth -- Kenneth Persson, kpersson@parcplace.com, (408)773-7462 Fax(408)481-0224 ParcPlace-Digitalk, Inc. 999 E. Arques Avenue, Sunnyvale, CA 95086-4593 "Install with this side down" From geoff Tue Aug 13 14:58:44 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA13197; Tue, 13 Aug 1996 14:58:44 -0400 Date: Tue, 13 Aug 1996 14:58:44 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608131858.AA13197@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: Re: question about whether unions carry exact discriminant information X-Omg-Issue: 66 Date: Tue, 13 Aug 1996 11:52:29 -0700 From: kpersson@parcplace.com (Kenneth Persson) To: janssen@parc.xerox.com, A.J.Eaton@nortel.co.uk Subject: Re: question about whether unions carry exact discriminant information Cc: orbos@omg.org Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Md5: R8WVFhaY8EG8BJRRxRaaxw== The discussion feels weird and I don't know where to start. - IDL is not language neutral, it is C/C++ biased. While this is sad, it is still a fact. =20 - A language mapping, specifies how the IDL constructs maps to the native language. The mapping should be close to the programming style of the language. The language mapping document is a user's guide. =20 - A language mapping, does not specify how to implement the language binging. The implementor of the language binding has to maintain the invariant and ergo keep the necisarry information around, sometimes the language environment does it, sometimes you need support objects to keep the extra information. Having said this, there are no problems having a Smalltalk ORB as a component in a heterogenoeos, distributed ORB environment. ParcPlace-Digitalk's Distributed Smalltalk has been tested together with several C++ ORB's. When=20 problems has been found it has always been in the C++ ORB. Statement like quoted below is simply not true: > As the Smalltalk language bindings stand, there are real > problems when trying to inter-work with C and C++ ORBs. > The authors of the Smalltalk binding seem to have only been > concerned with constructing Smalltalk only systems. The implementation of unions and anys in Distributed Smalltalk have been tricky at times. When the Smalltalk environment has the required meta information we use it, otherwise help objects has been implemented. What goes over the wire is always correct. /Kenneth > From A.J.Eaton@nortel.co.uk Fri Aug 2 04:14:16 1996 > From: A.J.Eaton@nortel.co.uk > Date: Fri, 2 Aug 96 11:20:34 BST > To: janssen@parc.xerox.com > Subject: Re: question about whether unions carry exact discriminant=20 information > Cc: orbos@omg.org >=20 > > I believe Ken Persson's response was most to the point. For = Smalltalk, > > the explicit mapping should be used for every service which may > > potentially communicate with another ORB. The implicit mapping = (natural > > as it is) should be deprecated. > > > > I still feel that IDL unions should be cleaned up. >=20 > Having implemented a Smalltalk ORB that NEEDED to inter-work with both = a C and > a C++ ORB, both unions and anys have caused problems.=20 >=20 > We have avoided the union problem by providing ONLY the explicit = mapping, but > CORBA anys are proving to be more problematical. The problems are = centered > around constructing a correct/valid CORBA TypeCode to ba passed as = part > of a CORBA any. In Smalltalk, certain information is just not = available: >=20 > o structure/union names > =09 > o a complete set of enumeration ids >=20 > o actual types of Integers, including those within unions > structures, sequences and arrays >=20 > and other information cannot be derived accurately: >=20 > o structure member ordering as defined in IDL >=20 > Some of this can be handled using a best guess approach, but other = information > (struct/union names, enum ids) must just be omitted. >=20 > We are currently looking at providing the option of allowing the = application > programmer to specify a TypeCode for a type to allow it to be = communicated to > C and C++ ORBs accurately: >=20 > asCORBAAny: anyValue typeCode: aTypeCode >=20 > This will require the generation of Smalltalk TypeCodes from IDL type=20 definitions > and will obviously be non-conformant to the Smalltalk binding. >=20 > As the Smalltalk language bindings stand, there are real problems when = trying > to inter-work with C and C++ ORBs. The authors of the Smalltalk = binding > seem to have only been concerned with constructing Smalltalk only = systems. >=20 > Thanks. >=20 > Anthony Eaton. >=20 > Senior Research Engineer,=20 > Distributed Systems and Services. > -- > Email: A.J.Eaton@bnr.co.uk Address: Nortel Technology, London Road, > Tel: +44 (0)1279 402742 Harlow, Essex, CM17 9NA, > Fax: +44 (0)1279 451866 United Kingdom From geoff Fri Aug 16 09:08:45 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA12567; Fri, 16 Aug 1996 09:08:45 -0400 Date: Fri, 16 Aug 1996 09:08:45 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608161308.AA12567@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: FW: question about whether unions carry exact discriminant information X-Omg-Issue: 66 From: Robert Larson To: "'orbos@omg.org'" Subject: FW: question about whether unions carry exact discriminant information Date: Thu, 15 Aug 1996 08:35:27 -0700 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, A colleage of mine has been forwarding messages to me from the orbos = mailing list regarding the discriminator information carried in unions = and the shortcomings of the Smalltalk language binding, etc. I had been = quietly observing from a distance as most of this was pretty well hashed = over during the development of the Smalltalk mapping. As a reviewer of the original Smalltalk mapping and as a contributor to = the implementation of commercially available ORBs in Smalltalk, I must = concur with Ken Persson and state that in my experience I have yet to = see any fundamental flaw in either the mapping of Unions/Anys or = Smalltalk ORBs in general. DST and Smalltalk Broker support both forms correctly. I would probably go even further than Ken however and promote the use of = the implicit binding of Unions in Smalltalk without exception. This = would discourage the use of the discriminator to propagate control = information which is: A) generally not a good thing to do (as it encourages coupling) B) better explicitly placed in the interface And frankly, I have not seen any practical reason to use the explicit = mapping other than to propagate this control information. Cheers, Robert Larson -------------------------------------------------------------------------= -------------------------------------------------------------- Robert Larson Windward Solutions Inc. email: larson@WindwardSolutions.com voice/fax: 1 415 367 7102 web: http://www.cerfnet.com/~windward ---------- >>Return-Path: >Errors-To: kpersson@central.parcplace.com >Date: Tue, 13 Aug 1996 11:52:29 -0700 >From: kpersson@parcplace.com (Kenneth Persson) >To: janssen@parc.xerox.com, A.J.Eaton@nortel.co.uk >Subject: Re: question about whether unions carry exact discriminant = information >Cc: orbos@omg.org >Content-Md5: R8WVFhaY8EG8BJRRxRaaxw=3D=3D > > >The discussion feels weird and I don't know where to start. > >- IDL is not language neutral, it is C/C++ biased. While > this is sad, it is still a fact. > =20 >- A language mapping, specifies how the IDL constructs > maps to the native language. The mapping should be > close to the programming style of the language. > The language mapping document is a user's guide. > =20 >- A language mapping, does not specify how to implement > the language binging. The implementor of the language > binding has to maintain the invariant and ergo keep > the necisarry information around, sometimes the language > environment does it, sometimes you need support objects > to keep the extra information. > >Having said this, there are no problems having a Smalltalk >ORB as a component in a heterogenoeos, distributed ORB >environment. ParcPlace-Digitalk's Distributed Smalltalk >has been tested together with several C++ ORB's. When=20 >problems has been found it has always been in the C++ ORB. > >Statement like quoted below is simply not true: > >> As the Smalltalk language bindings stand, there are real >> problems when trying to inter-work with C and C++ ORBs. >> The authors of the Smalltalk binding seem to have only been >> concerned with constructing Smalltalk only systems. > >The implementation of unions and anys in Distributed Smalltalk >have been tricky at times. When the Smalltalk environment has >the required meta information we use it, otherwise help objects >has been implemented. What goes over the wire is always correct. > >/Kenneth > >> From A.J.Eaton@nortel.co.uk Fri Aug 2 04:14:16 1996 >> From: A.J.Eaton@nortel.co.uk >> Date: Fri, 2 Aug 96 11:20:34 BST >> To: janssen@parc.xerox.com >> Subject: Re: question about whether unions carry exact discriminant=20 >information >> Cc: orbos@omg.org >>=20 >> > I believe Ken Persson's response was most to the point. For = Smalltalk, >> > the explicit mapping should be used for every service which may >> > potentially communicate with another ORB. The implicit mapping = (natural >> > as it is) should be deprecated. >> > >> > I still feel that IDL unions should be cleaned up. >>=20 >> Having implemented a Smalltalk ORB that NEEDED to inter-work with = both a C and >> a C++ ORB, both unions and anys have caused problems.=20 >>=20 >> We have avoided the union problem by providing ONLY the explicit = mapping, but >> CORBA anys are proving to be more problematical. The problems are = centered >> around constructing a correct/valid CORBA TypeCode to ba passed as = part >> of a CORBA any. In Smalltalk, certain information is just not = available: >>=20 >> o structure/union names >> =09 >> o a complete set of enumeration ids >>=20 >> o actual types of Integers, including those within unions >> structures, sequences and arrays >>=20 >> and other information cannot be derived accurately: >>=20 >> o structure member ordering as defined in IDL >>=20 >> Some of this can be handled using a best guess approach, but other information >> (struct/union names, enum ids) must just be omitted. >>=20 >> We are currently looking at providing the option of allowing the = application >> programmer to specify a TypeCode for a type to allow it to be = communicated to >> C and C++ ORBs accurately: >>=20 >> asCORBAAny: anyValue typeCode: aTypeCode >>=20 >> This will require the generation of Smalltalk TypeCodes from IDL type = >definitions >> and will obviously be non-conformant to the Smalltalk binding. >>=20 >> As the Smalltalk language bindings stand, there are real problems = when trying >> to inter-work with C and C++ ORBs. The authors of the Smalltalk = binding >> seem to have only been concerned with constructing Smalltalk only = systems. >>=20 >> Thanks. >>=20 >> Anthony Eaton. >>=20 >> Senior Research Engineer,=20 >> Distributed Systems and Services. >> -- >> Email: A.J.Eaton@bnr.co.uk Address: Nortel Technology, London Road, >> Tel: +44 (0)1279 402742 Harlow, Essex, CM17 9NA, >> Fax: +44 (0)1279 451866 United Kingdom > > ------------------------------------------------------------------ Ian J. Fuller Windward Solutions, Inc. 3108 Butte Street Santa Clara CA 95051 USA Tel: +1 408 984 8768 FAX: +1 408 984 8772 From geoff Mon Aug 26 14:40:19 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA17002; Mon, 26 Aug 1996 14:40:19 -0400 Date: Mon, 26 Aug 1996 14:40:19 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608261840.AA17002@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: more on unions and descriminators X-Omg-Issue: 66 From: Robert Larson To: "'T E Rutt'" Cc: "'orbos@omg.org'" Subject: more on unions and descriminators Date: Mon, 26 Aug 1996 11:18:00 -0700 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello, The message below leads me to think that there was some confusionabout = my response to the ongoing questions on unions. I did not mean to imply = that we don't send the descriminator in Smalltalk, we do. It is just = that it is (to my knowledge) the value of the descriminator is seldom if = ever used. You always deal with the object and allow the system to worry = about the discriminator and its value. With regards to the example below. I suppose one could design a system = which does use the descriminator of a union to specify some logic = control information. I would never define the interface this way (it = seems somewhat language specific). But if I had to support such an = interface in Smalltalk, I would merely use the explicit mapping. It is = not a problem. But don't get me started on need to use a union to specify a potentially = nil value. This is something that should have been accounted for in the = definition of types in the CORBA object model to begin with. Many = languages and all DBMSs directly support the notion of nilness of an = object of any type. It is a very common semantic construct. To require = the definition of a union to support such behavior is just plain wrong. We are forced to use this IDL construct in Smalltalk and by necessity, = often do. Robert ---------- From: T E Rutt[SMTP:ter@arch4.ho.att.com] Sent: Thursday, August 22, 1996 12:54 PM To: Robert Larson Subject: Re: FW: question about whether unions carry exact discriminant = information Robert It turns out that OMG IDL requires to send the discriminator. In fact, different semantic meanings can be send using the same data type. Logic contrtructs are one example, with two sequence having different semantics *or. of components vs and. Also, sending a discriminator value with the union, with a null arm is used to represent optional parameters. These are allowed and used in idl. Tom Rutt From geoff Wed Aug 28 11:42:13 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA10836; Wed, 28 Aug 1996 11:42:13 -0400 Date: Wed, 28 Aug 1996 11:42:13 -0400 From: geoff (Geoffrey Speare) Message-Id: <9608281542.AA10836@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: Re: more on unions and descriminators X-Omg-Issue: 66 Date: Mon, 26 Aug 1996 16:29:27 PDT Sender: Bill Janssen From: Bill Janssen To: "'T E Rutt'" , Robert Larson Subject: Re: more on unions and descriminators Cc: "'orbos@omg.org'" In-Reply-To: <01BB9342.4FE2AA40@default2.palto.cerfnet.com> Excerpts from local.omg: 26-Aug-96 more on unions and descrimi.. Robert Larson@windwardso (1931*) > But don't get me started on need to use a union to specify a potentially > nil value. This is something that should have been accounted for in the > definition of types in the CORBA object model to begin with. Many > languages and all DBMSs directly support the notion of nilness of an > object of any type. It is a very common semantic construct. To require > the definition of a union to support such behavior is just plain wrong. Yes, in ILU we added another type constructor called ``optional'' to support the notion of a value which may be NIL, or may be a value of the specified base type. Also nice for linked list or btree data structures, as it turns out. Also means we can receive object references without having to check each one for NIL-ness (since we can have object reference types which may be NIL, and ones which may not be). In IDL, `optional' might look something like struct foo { long a; long b; }; typedef optional foo bar; `foo' type values are always a struct value; `bar' type values may be a struct value, or may be NIL. In most programming languages, `optional' types are mapped to pointers. On the wire, it looks like a sequence with either 0 or 1 elements. Bill