Issue 1118: DynAny issue (03), CORBA 2.2 chapter 7 (port-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: * Page 7-9, section "Iterating through components of a DynAny": The first sentence in this section says that DynAny allows iteration through structs. It should make it clear that it also allows iteration through sequences, arrays, and unions as well. Resolution: Revised Text: Actions taken: March 31, 1998: received issue June 19, 1998: moved from orb_revision to port-rtf July 30, 1998: closed issue Discussion: Revision: Section 7.2.3 "The DynAny interface", Page 7-9, End of Annotations:===== Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Tue, 31 Mar 1998 18:57:46 -0500 To: orb_revision@omg.org, issues@omg.org From: Steve Vinoski Subject: more DynAny issues More DynAny issues. All page numbers are for CORBA 2.2, Chapter 7. * Page 7-9, section "Iterating through components of a DynAny": The first sentence in this section says that DynAny allows iteration through structs. It should make it clear that it also allows iteration through sequences, arrays, and unions as well. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 9 Jul 1998 16:28:09 +1000 (EST) From: Michi Henning To: port-rtf@omg.org Subject: Issue 1118 Steve said: * Page 7-9, section "Iterating through components of a DynAny": The first sentence in this section says that DynAny allows iteration through structs. It should make it clear that it also allows iteration through sequences, arrays, and unions as well. I don't think I can iterate through a *union*, because a union has only one member (the active member). Or is iteration over a union meant to give me the discriminator as the first component and the active member as the second? If so, that needs to be said. What does iteration over a sequence or an array do? Get me each successive element? If so, why do this? Isn't it sufficient that I can get at the sequence and contents already with get_elements()? I'm beginning to suspect that iteration only makes sense for exceptions and structures, and isn't need for anything else at all. If that is the consensus, the iterator operations should be moved out of DynAny and should go into DynStruct instead, because that's the only thing they apply to. While we are at it, why don't we axe rewind()? It is redundant, because it does the same as seek(0). I think rewind() is bad style: one sign of a "good" interface is that it is both sufficient and minimal. rewind() isn't miminal because it does the same as seek(0). In addition, there is no saving in calling rewind() over calling seek(0), so we might as well drop it. Opinions? Do iterator operations *really* apply to types other than exceptions and strutures? Should we drop rewind()? 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: Thu, 09 Jul 1998 08:09:50 -0700 From: Jonathan Biggar To: Michi Henning CC: port-rtf@omg.org Subject: Re: Issue 1118 References: Michi Henning wrote: > > Steve said: > > * Page 7-9, section "Iterating through components of a > DynAny": The > first sentence in this section says that DynAny allows > iteration > through structs. It should make it clear that it also allows > iteration through sequences, arrays, and unions as well. > > I don't think I can iterate through a *union*, because a union has > only > one member (the active member). Or is iteration over a union meant > to give me the discriminator as the first component and the active > member > as the second? If so, that needs to be said. I believe that is what the text implies. > What does iteration over a sequence or an array do? Get me each successive > element? If so, why do this? Isn't it sufficient that I can get at the > sequence and contents already with get_elements()? > > I'm beginning to suspect that iteration only makes sense for exceptions > and structures, and isn't need for anything else at all. Iteration over sequences and arrays makes a lot of sense when there are hundreds or thousands of elements and I don't want to allocate the space for the return value of get_elements(). > If that is the consensus, the iterator operations should be moved > out of DynAny and should go into DynStruct instead, because that's > the only > thing they apply to. > > While we are at it, why don't we axe rewind()? It is redundant, > because > it does the same as seek(0). I think rewind() is bad style: one sign > of a "good" interface is that it is both sufficient and > minimal. rewind() > isn't miminal because it does the same as seek(0). In addition, > there > is no saving in calling rewind() over calling seek(0), so we might > as > well drop it. I agree, that there is no need for rewind, but there isn't a great need to remove it at this point either. > Opinions? Do iterator operations *really* apply to types other than > exceptions and strutures? Should we drop rewind()? Yes, keep the iterator operations for all structured types. It can be too memory intensive to extract the entire contents of a structured type all at once. The iterators provide a single element access that is more memory friendly. There is no particular reason to remove iteration for unions as a special case either. -- 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: Fri, 10 Jul 1998 04:04:39 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: port-rtf@omg.org Subject: Re: Issue 1118 On Thu, 9 Jul 1998, Jonathan Biggar wrote: > > I don't think I can iterate through a *union*, because a union has only > > one member (the active member). Or is iteration over a union meant > > to give me the discriminator as the first component and the active member > > as the second? If so, that needs to be said. > > I believe that is what the text implies. Well, right now, it says: The DynAny interface allows a client to iterate through the components of the struct data value pointed by a DynStruct object. As Steve pointed out, that doesn't mention unions, sequences, and arrays. > Iteration over sequences and arrays makes a lot of sense when there are > hundreds or thousands of elements and I don't want to allocate the space > for the return value of get_elements(). I can accept that. > I agree, that there is no need for rewind, but there isn't a great need > to remove it at this point either. Well, it's ugly. Do we really want to retain it. This really is the question of how much harm is done by a redundant operation. In my opinion, it needlessly complicates the interface, which is bad. In addition, it always raises the niggling question in the reader's mind: "Why is there a rewind if it is the same as seek(0)? Is there something subtly different between the two that I'm not seeing?" I'd be in favour of removing rewind while we still have the chance (right now, there should be precious little source code out there that relies on it, and what little there is would be trivial to fix if rewind goes). > Yes, keep the iterator operations for all structured types. It can be > too memory intensive to extract the entire contents of a structured type > all at once. The iterators provide a single element access that is more > memory friendly. There is no particular reason to remove iteration for > unions as a special case either. Fine. In that case, we need to state that iteration applies to structures, exceptions, unions, sequences, and arrays. For unions, iteration gives me the discriminator as the first component and the member as the second component. For exceptions and structs, iteration delivers members in the order in which they appear in the IDL. For sequences and arrays, iteration delivers elements in order of increasing index. Will that do? 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: From: "Daniel R. Frantz" To: , Subject: RE: Proposals for issues 118, 119, 120, 121, 122 Date: Thu, 9 Jul 1998 14:36:09 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >-----Original Message----- >From: Steve Vinoski [mailto:vinoski@iona.com] >Sent: Wednesday, July 08, 1998 11:30 PM >To: Jonathan Biggar >Cc: Daniel R. Frantz; port-rtf@omg.org >Subject: Re: Proposals for issues 118, 119, 120, 121, 122 [...] >For issue 1118, the list should also include DynValue. What Steve is referring to is that the Objects By Value specification added DynValue. OBV isn't in CORBA 2.2 but will be in CORBA 2.3 so we should include DynValue. Unless I hear otherwise, I'm going to assume that this is acceptable to all voters and include it in the final report without taking yet another vote. (An editorial change to an editorial change!) One question. For you crossover members of the OBV-RTF, I believe the OBV RTF has finally, irrevocably agreed that "value" will no longer be the keyword for those new thingies as of the RTF completion (July 30). Will OBV-RTF change the DynValue part of the OBV specification? Should this be DynValueType instead? Dan Return-Path: X-Sender: vinoski@mail.boston.iona.ie Date: Thu, 09 Jul 1998 15:11:11 -0400 To: Michi Henning From: Steve Vinoski Subject: Re: Issue 1118 Cc: port-rtf@omg.org References: <35A4DD3E.95E14F0C@floorboard.com> At 04:04 AM 7/10/98 +1000, Michi Henning wrote: >On Thu, 9 Jul 1998, Jonathan Biggar wrote: > >> > I don't think I can iterate through a *union*, because a union has only >> > one member (the active member). Or is iteration over a union meant >> > to give me the discriminator as the first component and the active member >> > as the second? If so, that needs to be said. >> >> I believe that is what the text implies. > >Well, right now, it says: > > The DynAny interface allows a client to iterate through the components > of the struct data value pointed by a DynStruct object. > >As Steve pointed out, that doesn't mention unions, sequences, and arrays. Yes, but the last paragraph of the DynUnion section specifies that iteration first returns the discriminator and then returns the member. >> I agree, that there is no need for rewind, but there isn't a great need >> to remove it at this point either. > >Well, it's ugly. Do we really want to retain it. This really is the question >of how much harm is done by a redundant operation. In my opinion, it needlessly >complicates the interface, which is bad. In addition, it always raises >the niggling question in the reader's mind: "Why is there a rewind if >it is the same as seek(0)? Is there something subtly different between the >two that I'm not seeing?" Well, the C library contains both fseek and rewind... I agree with Jon -- leaving it does no real harm. >Fine. In that case, we need to state that iteration applies to structures, >exceptions, unions, sequences, and arrays. For unions, iteration gives >me the discriminator as the first component and the member as the second >component. For exceptions and structs, iteration delivers members in >the order in which they appear in the IDL. For sequences and arrays, >iteration delivers elements in order of increasing index. > >Will that do? Sounds good to me. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 10 Jul 1998 08:07:33 +1000 (EST) From: Michi Henning To: Steve Vinoski cc: port-rtf@omg.org Subject: Re: Issue 1118 On Thu, 9 Jul 1998, Steve Vinoski wrote: > At 04:04 AM 7/10/98 +1000, Michi Henning wrote: > >On Thu, 9 Jul 1998, Jonathan Biggar wrote: > > > >> > I don't think I can iterate through a *union*, because a union > has only > >> > one member (the active member). Or is iteration over a union > meant > >> > to give me the discriminator as the first component and the > active member > >> > as the second? If so, that needs to be said. > >> > >> I believe that is what the text implies. > > > >Well, right now, it says: > > > > The DynAny interface allows a client to iterate through the > components > > of the struct data value pointed by a DynStruct object. > > > >As Steve pointed out, that doesn't mention unions, sequences, and > arrays. > > Yes, but the last paragraph of the DynUnion section specifies that > iteration first returns the discriminator and then returns the > member. Oops, how embarrassing. I plain missed that :-( > Well, the C library contains both fseek and rewind... > > I agree with Jon -- leaving it does no real harm. OK. I give in ;-) > > >Fine. In that case, we need to state that iteration applies to > structures, > >exceptions, unions, sequences, and arrays. For unions, iteration > gives > >me the discriminator as the first component and the member as the > second > >component. For exceptions and structs, iteration delivers members > in > >the order in which they appear in the IDL. For sequences and > arrays, > >iteration delivers elements in order of increasing index. > > > >Will that do? > > Sounds good to me. > > --steve 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: From: "Daniel R. Frantz" To: Subject: RE: Issue 1118 Date: Thu, 9 Jul 1998 23:03:41 -0400 X-MSMail-Priority: Normal Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 >From: Michi Henning [mailto:michi@dstc.edu.au] >>On Thu, 9 Jul 1998, Steve Vinoski wrote: >>> At 04:04 AM 7/10/98 +1000, Michi Henning wrote: >>> >On Thu, 9 Jul 1998, Jonathan Biggar wrote: Hmmm... My brains are fried. Is it the conclusion that we don't have to do anything else or that we should? The current proposal already has 8 votes (out of 11). If anybody wants to change the result, we need exact words. As a reminder, what I have listed for the current proposal is: =================================================================== Issue 1118: DynAny: iteration clarification Nature: Clarification Summary: Page 7-9, section "Iterating through components of a DynAny". The first sentence in this section says that DynAny allows iteration through structs. It should make it clear that it also allows iteration through sequences, arrays, and unions as well. Resolution: Accepted for Corba RTF 2.3 Revision: Section 7.2.3 "The DynAny interface", Page 7-9, unnumbered section "Iterating through components of a DynAny". Change the first sentence to: "The DynAny interface allows a client to iterate through the components of the values pointed to by DynStruct, DynSequence, DynArray, DynUnion, and DynAny objects." Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 10 Jul 1998 13:09:30 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: Steve Vinoski , port-rtf@omg.org Subject: Re: Proposals for issues 118, 119, 120, 121, 122 On Thu, 9 Jul 1998, Jonathan Biggar wrote: > > member_name() returns: > > > > - the name of the currently active member > > > > - the empty string if the type code doesn't have member > names > > > > - the string "_default" if the default member is active > > This isn't right. This "default" member (the member associated with > the > "default:" label already has a member name. No need for "_default". Oops, you are right of course. I confused the label with the member... > > - the string "_none" if no member is active > > The case where no member is active is apparently the situation > intended > to be detected by the set_as_default() attribute. I don't think it would hurt to keep this though -- it means I can call member_name without having to check anything else first. > Now that I think about the issue of DynAny exception cases, the less I > think that things need to be changed drastically. Calling things like > member_name() and member_kind() when there is no union member could be > considered a programming error, which should never happen, since the > interface (via the TypeCode) provides enough information for the > programmer to avoid the condition. In these cases for the DynAny > interface, I am now inclined to just state that these are cases where > undefined behavior occurs, rather than specifically nail down what > exception is raises (or even if an exception is raised at all rather > than a core dump). I think I agree overall (reluctantly). The current interface isn't exactly a model of elegance, but conversations with Steve Vinoski have convinced me that it can be made to work (you have to accept hidden communication between a DynUnion object and its components though). However, if we keep what is there, I would still suggest two minor changes: - Make set_as_default readonly and call it "is_default" instead. I simply cannot see any meaninful semantics for writing this attribute. - Make member_name readonly, for the same reason. 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: Fri, 10 Jul 1998 13:18:38 +1000 (EST) From: Michi Henning To: "Daniel R. Frantz" cc: port-rtf@omg.org Subject: RE: Issue 1118 On Thu, 9 Jul 1998, Daniel R. Frantz wrote: > Hmmm... My brains are fried. Is it the conclusion that we don't have to > do anything else or that we should? Sorry Dan - the DynUnion interface fried my brain too :-) > The current proposal already has 8 votes (out of 11). If anybody wants > to change the result, we need exact words. I'd like to amend the proposal according to my previous email (rename set_as_default to is_default and make it readonly, and make member_name readonly). 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: Thu, 09 Jul 1998 20:57:22 -0700 From: Jonathan Biggar To: Michi Henning CC: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: Issue 1118 References: Michi Henning wrote: > > On Thu, 9 Jul 1998, Daniel R. Frantz wrote: > > > Hmmm... My brains are fried. Is it the conclusion that we don't > have to > > do anything else or that we should? > > Sorry Dan - the DynUnion interface fried my brain too :-) > > > The current proposal already has 8 votes (out of 11). If anybody > wants > > to change the result, we need exact words. > > I'd like to amend the proposal according to my previous email > (rename > set_as_default to is_default and make it readonly, and make > member_name > readonly). As I have said previously, I disagree with these changes. The interface may be crufty, but it can be made to work. Changing this stuff would break existing implementations or client code, simply to make the interface cleaner. I don't find that a sufficient argument to justify the pain level. -- 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: Fri, 10 Jul 1998 14:04:39 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: "Daniel R. Frantz" , port-rtf@omg.org Subject: Re: Issue 1118 On Thu, 9 Jul 1998, Jonathan Biggar wrote: > As I have said previously, I disagree with these changes. The interface > may be crufty, but it can be made to work. Changing this stuff would > break existing implementations or client code, simply to make the > interface cleaner. I don't find that a sufficient argument to justify > the pain level. OK, I accept that. But what *are* the semantics of setting the set_as_default and member_name attributes then? I still can't understand that, sorry :-( 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: vinoski@mail.boston.iona.ie Date: Fri, 10 Jul 1998 00:19:22 -0400 To: Michi Henning From: Steve Vinoski Subject: RE: Issue 1118 Cc: "Daniel R. Frantz" , port-rtf@omg.org References: <004101bdabaf$5912e940$3fc5bdce@idler.beasys.com> At 01:18 PM 7/10/98 +1000, Michi Henning wrote: >On Thu, 9 Jul 1998, Daniel R. Frantz wrote: >> The current proposal already has 8 votes (out of 11). If anybody wants >> to change the result, we need exact words. > >I'd like to amend the proposal according to my previous email (rename >set_as_default to is_default and make it readonly, and make member_name >readonly). Michi, I think Dan is only talking about how to fix the "iterate over structs" words to include all the other DynWhatevers that can be iterated over. The DynUnion issue is 1120, not 1118. --steve Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Fri, 10 Jul 1998 14:26:22 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: Steve Vinoski cc: "Daniel R. Frantz" , port-rtf@omg.org Subject: RE: Issue 1118 On Fri, 10 Jul 1998, Steve Vinoski wrote: > Michi, I think Dan is only talking about how to fix the "iterate over > structs" words to include all the other DynWhatevers that can be iterated > over. The DynUnion issue is 1120, not 1118. Oh no, now I've added even more to the confusion! My apologies. I think the consensus was that iteration applies to structs, unions, exceptions, sequences, and arrays, and that we need to say this. I think adding the words I suggested about the order in which components are iterated over wouldn't hurt either. 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