Issue 1541: Type code typos (as only one issue) (orb_revision) Source: (, ) Nature: Revision Severity: Minor Summary: Summary: There are a few typos in the spec for type codes. Page 8-40: A structure with N members results in a tk_struct TypeCode with 2N+1 parameters. This is no longer correct. Because of the Repository ID parameter that was added, this is now 2N+2. Similar fixes need to be applied to the text for unions (3N+3 parameters, not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by the text), and aliases (they have three parameters, not two). The text for tk_objref also needs updating, because it states that it has one parameter instead of two. Also, Table 7-1 for tk_objref should be updated because it is internally inconsistent. 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 12:27:35 +1000 (EST) From: Michi Henning To: orb_revision@omg.org, issues@omg.org Subject: Type code typos Hi, There are a few typos in the spec for type codes. Page 8-40: A structure with N members results in a tk_struct TypeCode with 2N+1 parameters. This is no longer correct. Because of the Repository ID parameter that was added, this is now 2N+2. Similar fixes need to be applied to the text for unions (3N+3 parameters, not 3N+2), enumerations (N+2 parameters instead of N+1 as implied by the text), and aliases (they have three parameters, not two). The text for tk_objref also needs updating, because it states that it has one parameter instead of two. Also, Table 7-1 for tk_objref should be updated because it is internally inconsistent. For tk_objref, it shows: tk_objref { interface-id } interface name However, the text makes it clear that "interface-id" is a repository ID, and table 7-1 uses "RepositoryId" elsewhere for the same purpose. So, "interface-id" in Table 7-1 should be replaced by "RepositoryId" for consistency. The newly added items of information (shown in the "NOT VISIBLE" column of Table 8-1) are not mentioned in the definition of the member_count() operation. The text only says that "Member_count returns the number of members constituting the type." This is ambiguous, because it is not clear whether member_count() returns the count including or excluding the newly added items in the NOT VISIBLE column. I believe the intent is that it should *include* these, and the text should state this explicitly. The second para on page 8-38 has the wrong spelling for operation names. It is "member_count" and "member_name" instead of "Member_count" and "Member_name". The fourth para on page 8-38 has the same problem. Should be "member_label", not "Member_label". Second para states: The member_count and member_name operations can be invoked on structure, union, and enumerations TypeCodes. This is incorrect, they also apply to exception type codes. First para on page 8-39 doesn't make much sense as it stands: "The deprecated param_count and parameter operations provide access to those parameters that were present in previous versions of CORBA." What does that mean? It seems to imply that param_count() and parameter() can do something that member_count() and member_name() cannot. But of course, it just means that they behave as if the NOT_VISIBLE column in Table 8-1 did not exist. The text goes on: "Some information available via other TypeCode operations is not visible via the parameter operation." *Which* information is "some information"? Of course, it means the information in the NOT VISIBLE column, but the text never actually says so. Also, the text never says that the bits that are not visible via the deprecated operations *is* visible via the ones that are not deprecated. Why does the spec define operations that are deprecated? After all, if they are deprecated, that means they should no longer be used, so it seems pointless to provide a definition for something that is deprecated. Wouldn't it make more sense to remove all references to param_count() and parameter() and to clean up Table 8-1 to integrate the NOT VISIBLE column into the PARAMETER LIST column? The TCKind enumeration contains the tk_Principal enumerator, but the text makes no mention of it anywhere. To someone who does not know that the Principal object has been deprecated, this raises the question of whether that's a bug or intentional. I would suggest to add footnote or some such to state that tk_Principal is deprecated, but retained in TCKind to avoid interoperability problems due to the enumerator ordinal values going out of synch. 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: Wed, 15 Jul 1998 17:21:18 -0400 From: Bob Kukura Organization: IONA Technologies To: orb_revision@omg.org Subject: ORB revision Vote 3 - problem with issue 1541 I apologize for not paying enough attention to orb_revision the past few weeks to provide comments before a vote has been called, but I think it would be a big mistake to approve the proposed resolution for issue 1541 having to do with TypeCode::parameter() and TypeCode::param_count(). The CORBA 2.0 Interface Repository RFP submitters found the need to extend the information contained in certain kinds of TypeCodes. The CORBA 1.x TypeCode pseudo-interface only provided the kind(), parameters(), param_count(), and equal() operations. But the submitters realized that any attempt to extend the list of parameters, particularly for struct, union, and enum TypeCodes that have a fixed number of parameters followed by a variable length list of per-member parameters, would break existing code. Therefore, we (I admit involvement) decided to deprecate parameter() and param_count() and replace them with a "fat-interface" approach to accessing the same information. We intentionally did not change the numbering of existing parameters or attempt to provide access to the new information via parameters() in order to not break source compatability with existing CORBA 1.x code. The proposed resolution to issue 1541 would change the meaning of the indices passed to TypeCode::parameter(), and would mean CORBA 2.3 would not be source compatable for TypeCode::parameter() with any of the previous versions of CORBA, all of which were source compatable for this operation. CORBA 2.2 already says "The deprecated param_count and parameter operations..." on page 8-39. Deprecated features such as this should either be left alone or removed, but should not be changed. I think the right thing to do in CORBA 2.3 is to completely remove the TypeCode::param_count() and TypeCode::parameter() operations and this whole concept of TypeCode parameters from the specification. ORB vendors could still continue to support them as long as they felt that it was in their customers' interest, but this RTF would no longer have to deal with the confusion they cause, and future specifications or revisions would not accidently introduce additional dependencies on them. This change would require removing: // deprecated interface long param_count (); any parameter (in long index) raises (Bounds); from the TypeCode pseudo-IDL on page 8-37, and removing the text begining with "The deprecated param_count and parameter operations..." at the top of page 8-39 and ending just before section 8.7.2 on page 8-40. The CDR encoding of TypeCode would continue to be specified in terms of CDR-specific parameter lists, but there would no longer be any confusion between these parameters and the ones being removed from the specification. -Bob Return-Path: Sender: jon@floorboard.com Date: Wed, 15 Jul 1998 14:58:46 -0700 From: Jonathan Biggar To: Bob Kukura CC: orb_revision@omg.org Subject: Re: ORB revision Vote 3 - problem with issue 1541 References: <35AD1D4E.DCD0454D@iona.com> Bob Kukura wrote: > The proposed resolution to issue 1541 would change the meaning of > the > indices passed to TypeCode::parameter(), and would mean CORBA 2.3 > would > not be source compatable for TypeCode::parameter() with any of the > previous versions of CORBA, all of which were source compatable for > this > operation. CORBA 2.2 already says "The deprecated param_count and > parameter operations..." on page 8-39. Deprecated features such as > this > should either be left alone or removed, but should not be changed. Oops. You are entirely right Bob. I withdraw my yes vote on 1541. -- 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: Thu, 16 Jul 1998 08:48:56 +1000 (EST) From: Michi Henning Reply-To: Michi Henning To: Bob Kukura cc: orb_revision@omg.org Subject: Re: ORB revision Vote 3 - problem with issue 1541 On Wed, 15 Jul 1998, Bob Kukura wrote: > I think the right thing to do in CORBA 2.3 is to completely remove the > TypeCode::param_count() and TypeCode::parameter() operations and this > whole concept of TypeCode parameters from the specification. ORB > vendors could still continue to support them as long as they felt that > it was in their customers' interest, but this RTF would no longer have > to deal with the confusion they cause, and future specifications or > revisions would not accidently introduce additional dependencies on > them. > > This change would require removing: > > // deprecated interface > long param_count (); > any parameter (in long index) raises (Bounds); > > from the TypeCode pseudo-IDL on page 8-37, and removing the text > begining with "The deprecated param_count and parameter operations..." > at the top of page 8-39 and ending just before section 8.7.2 on page > 8-40. I completely agree with Bob. There is no point in continuing to document deprecated operations. In the initial issue, I suggested to remove these operations too. 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