Issue 1121: DynAny issue (06), CORBA 2.2 chapter 7 (port-rtf) Source: (, ) Nature: Revision Severity: Summary: Summary: * Page 7-13, section 7.2.8: the description of the "length" attribute for DynSequence says that the length is set to zero for unbounded sequences. This is useless as it confuses bound with length. That part of the sentence should be removed. If I want to know the sequence bound, I can ask its TypeCode. The DynSequence length attribute should be used to get/set the actual length of the sequence in the DynSequence regardless of whether its bounded or unbounded. 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: 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-13, section 7.2.8: the description of the "length" attribute for DynSequence says that the length is set to zero for unbounded sequences. This is useless as it confuses bound with length. That part of the sentence should be removed. If I want to know the sequence bound, I can ask its TypeCode. The DynSequence length attribute should be used to get/set the actual length of the sequence in the DynSequence regardless of whether its bounded or unbounded. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Thu, 9 Jul 1998 11:10:19 +1000 (EST) From: Michi Henning To: port-rtf@omg.org Subject: Issue 1121, DynAny sequence length Steve already pointed out that the spec confuses length with bound for DynSequence. However, I'm still having a problem with the length attribute. For example, what should happen if I set the length to 10, then call set_elements with a sequence of length 10, and then call set_elements again with a sequence of length 5? Which elements will be replaced? Similarly, what should happen if I set the length to 10, and then call set_elements *twice*, with a sequence of five elements each time? Should the second call replace the first five elements or should it add five elements? I think the length attribute really should not be writable. I believe if we make it readonly, most of the problems go away. In particular, we can then specify that calling set_elements always sets *all* elements of the sequence and as a side-effect, it adjusts the length attribute to the length of the sequence passed to set_elements. In addition, I think we should state that when I create a DynSequence, it is created with zero elements. 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: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