Issue 1543:  Type code parameter ordering (orb_revision)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: 
 the TypeCode pseudo interface makes no mention about the order of parameters
 for structured types. For example, given the IDL struct
 
 	struct MyStruct {
 		char	c_mem;
 		string	s_mem;
 	};
 
 it is legal for member_name(0) to return "s_mem" and member_name(1) to
 return "c_mem" (provided member_type(0) returns a char type code and
 member_type(1) returns a string type code).
 
 The same comments apply to unions, exceptions, and enums, where the order
 in which members are presented is not necessarily the same order as in the IDL
 definition.
 

Resolution: 
Revised Text: 
Actions taken:
June 24, 1998: received issue
Discussion: 

End of Annotations:=====
Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Wed, 24 Jun 1998 14:01:04 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: issues@omg.org, orb_revision@omg.org
Subject: Type code parameter ordering

Hi,

the TypeCode pseudo interface makes no mention about the order of
parameters
for structured types. For example, given the IDL struct

	struct MyStruct {
		char	c_mem;
		string	s_mem;
	};

it is legal for member_name(0) to return "s_mem" and member_name(1) to
return "c_mem" (provided member_type(0) returns a char type code and
member_type(1) returns a string type code).

The same comments apply to unions, exceptions, and enums, where the
order
in which members are presented is not necessarily the same order as in
the IDL
definition.

Is this truly intentional? You could argue that it does not matter for
unions,
but member order is significant for structures, exceptions, and enums.

Suppose I want to use Type Codes to unmarshal data off the wire. With
the current interface, I can't unmarshal a structure or exception,
because
the TypeCode conceivably could give me the members in a different
order
than the order in which they appear in on the wire. This means I am
forced
to use some other interface to the type code to unmarshal reliably. 

Proposal: Tighten the spec to require the members to be ordered the
same
way as in the IDL for structures, exceptions, unions, and
enums. Virtually
every ORB will already behave like this anyway, so it won't do any
harm,
but will tighten the spec.

For enums, this is essential, because otherwise, I lose knowledge of
which
ordinal value belongs to what enumerator. (Because there is no
separate
operation to get the ordinal value, the index for each enumerator *is*
the ordinal value.)

For unions, maintaining order isn't strictly necessary, but it would
be
nice to fix it for unions as well (I'll raise a separate issue which
relates
to this for the CDR marshalling of union type codes).

							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: <javier@cnd.hp.com>
Date: Mon, 13 Jul 1998 11:43:22 -0600
From: Javier Lopez-Martin <javier@cnd.hp.com>
To: orb_revision@omg.org, jis@fpk.hp.com
Subject: Re: My homework issues 918, 1541, 1542, 1543, 1585, 1587 +
revised 724
Content-Md5: M821D9D6mRQhO289U0bKUw==

Hi Jishnu,

A small typo at the end of the resolution text for 1543.

It says:

"... and member3 has index = 3."

While it should say:

"... and member3 has index = 2."

Javier

--

Javier Lopez-Martin
Hewlett-Packard Co
javier@cnd.hp.com