Issue 1545: Type codes cannot describe all unions (orb_revision) Source: (, ) Nature: Revision Severity: Summary: Summary: Fix this by stating that member_label returns an Any containing a *sequence* of labels if a single member has more than label. Add a typedef to the TypeCode pseudo-IDL: typedef sequence<any> LabelSeq; A sequence of this type would be contained in the Any returned by member_label() if a member has multiple labels (this avoids changing the signature of member_label()). For the above union, the member_count() operation would return 2, not 5. Resolution: Revised Text: Actions taken: June 24, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 24 Jun 1998 14:26:03 +1000 (EST) From: Michi Henning To: issues@omg.org, orb_revision@omg.org Subject: Type codes cannot describe all unions Consider the union: union u switch (long) { case 0: case 1: case 2: case 3: double d_mem; case 4: string s_mem; }; >From the spec (page 8-38): "Member_label [sic] returns the label of the union member identified by index." So what should member_label() return for the member d_mem? As far as I can see, this is completely undefined right now. Similarly, what should member_count() return? Again, this seems undefined. With the current signature of member_label(), the only way I can see to describe this union would be to return a member_count() of 5, with member_name() returning "d_mem" for index values of 0, 1, 2, and 3. However, this is no more than a guess, and seems awfully confusing. To reconstruct the union definition from its type code, I would have to filter for duplicate member names to realize when a single member has multiple labels. Suggestion: Fix this by stating that member_label returns an Any containing a *sequence* of labels if a single member has more than label. Add a typedef to the TypeCode pseudo-IDL: typedef sequence LabelSeq; A sequence of this type would be contained in the Any returned by member_label() if a member has multiple labels (this avoids changing the signature of member_label()). For the above union, the member_count() operation would return 2, not 5. Opinions anyone? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 24 Jun 1998 15:19:10 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: issues@omg.org, orb_revision@omg.org Subject: Re: Type codes cannot describe all unions On Tue, 23 Jun 1998, Jonathan Biggar wrote: > Michi, you have missed the text in the IFR that describes this, section > 8.5.10: "Adjacent members [of unions] can have the same name. Members > with the same name must also have the same type.". This also strongly > suggests that the members should appear in the same order as the IDL. Thanks for the hint Jon! I know that this is how a number of current implementations do it. But that doesn't remove the defect in the spec. For one, as you say, this suggests that for unions, member_count() counts case labels instead of members. However, why should I have to read section 8.5.10 to understand the semantics of the operations in section 8.7.1? After all, 8.7.1 describes the semantics of these operations, so it might as well describe them completely. Also, the words in the spec are most certainly wrong if your interpretation is correct: Member_count [sic] returns the number of members constituting the type. In the absence of further explanation, that means members, not case labels. So, we need to - Agree on what member_count() and member_type() should return for multiple case labels. I suspect that my earlier suggestion may cause too much grief to implement now, so we may have to go with the current behavior as Jon explained. - Once we have decided how multiple case labels are dealt with, the operation descriptions in section 8.7.1 need to be tightened to match. 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: Sender: jon@floorboard.com Date: Tue, 23 Jun 1998 22:35:11 -0700 From: Jonathan Biggar To: Michi Henning CC: issues@omg.org, orb_revision@omg.org Subject: Re: Type codes cannot describe all unions References: Michi Henning wrote: > > On Tue, 23 Jun 1998, Jonathan Biggar wrote: > > > Michi, you have missed the text in the IFR that describes this, > section > > 8.5.10: "Adjacent members [of unions] can have the same name. > Members > > with the same name must also have the same type.". This also > strongly > > suggests that the members should appear in the same order as the > IDL. > > Thanks for the hint Jon! > > I know that this is how a number of current implementations do it. > But that doesn't remove the defect in the spec. For one, as you say, > this suggests that for unions, member_count() counts case labels > instead > of members. However, why should I have to read section 8.5.10 to > understand the semantics of the operations in section 8.7.1? After > all, 8.7.1 describes the semantics of these operations, so it might > as well describe them completely. Yup, we need to make it airtight. If the reader studies the IFR part, the TypeCode part, and the GIOP CDR encoding part of the spec, and then mulls on it for a month or so, the reader should come up with the same answer as I did: Whenever the spec talks about a "member" of a union, it is talking about each individual discriminator label value, not just the name and type part. > Also, the words in the spec are most certainly wrong if your interpretation > is correct: > > Member_count [sic] returns the number of members constituting > the type. > > In the absence of further explanation, that means members, not case labels. > > So, we need to > > - Agree on what member_count() and member_type() should return > for multiple case labels. One member for each case. > I suspect that my earlier suggestion may cause too much grief > to implement now, so we may have to go with the current behavior > as Jon explained. I believe that several ORBs are implemented in this fashion already. > - Once we have decided how multiple case labels are dealt with, > the operation descriptions in section 8.7.1 need to be tightened > to match. Repeat after me: One member for each discriminator label. One member for each discriminator label. One member for each discriminator label. One member for each discriminator label. One member for each discriminator label. One member for each discriminator label. One member for each discriminator label. One member for each discriminator label. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 24 Jun 1998 19:46:10 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: issues@omg.org, orb_revision@omg.org Subject: Re: Type codes cannot describe all unions On Tue, 23 Jun 1998, Jonathan Biggar wrote: > > Repeat after me: One member for each discriminator label. One > member > for each discriminator label. One member for each discriminator > label. > One member for each discriminator label. One member for each > discriminator label. One member for each discriminator label. One > member for each discriminator label. One member for each > discriminator > label. :-) OK, OK, I got it the first time... So, all we need to do is codify the current behavior (as much as it pains me to have to say that ;-) I'll post some words to that effect tomorrow. 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