Issue 1671:  DynAny: sometimes Any, sometimes DynAny? (port-rtf)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: Something a bit strange about component types for DynAny...
 
 For unions, the discriminator and the active member are controlled as
 type DynAny. For sequences and arrays, they are sequences of *any* (not
 DynAny). Yet, when I iterate over a sequence or array, the members are
 dealt with as type DynAny (instead of any).
 
 For structures, if I access the members via iteration, they are accessed
 as type DynAny, whereas if I use set_members() and get_members(), they
 are sequences of name-*any* pairs, not sequences of name-*DynAny* pairs.
 
 I don"t see why, in some cases, components are dealt with as type any,
 and in other cases, they are dealt with as DynAny. Any particular reason?
 
 

Resolution: 
Revised Text: 
Actions taken:
July 13, 1998: received issue
February 22, 1999: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Mon, 13 Jul 1998 14:48:41 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: issues@omg.org, port-rtf@omg.org
Subject: DynAny: sometimes Any, sometimes DynAny?

Something a bit strange about component types for DynAny...

For unions, the discriminator and the active member are controlled as
type DynAny. For sequences and arrays, they are sequences of *any*
(not
DynAny). Yet, when I iterate over a sequence or array, the members are
dealt with as type DynAny (instead of any).

For structures, if I access the members via iteration, they are
accessed
as type DynAny, whereas if I use set_members() and get_members(), they
are sequences of name-*any* pairs, not sequences of name-*DynAny*
pairs.

I don't see why, in some cases, components are dealt with as type any,
and in other cases, they are dealt with as DynAny. Any particular
reason?

I found this rather inconvenient, particularly when composing
structures
using DynAny to dynamically compose the members. The fact that
set_members()
requires the members as type any means that after I have built the
DynAny
for a member, I now have to convert it into an any before I can assign
the member value into the sequence. The additional conversion step
could be avoided if the DynAny interface always dealt with components
as type DynAny. It also would simplify the interface.

Similar arguments apply to composing sequences and arrays. The
set_elements()
operation requires sequences of any, but if I dynamically compose the
sequence elements, I have to convert each element into an any first.

I know I can use iteration to deal with everything as a DynAny, but
then,
for consistency, the DynUnion should return the discriminator and
member
as type any instead of DynAny. (DynUnion is the odd one out, because
it
deals with the components as DynAny, but all the other complex types
use any for the operations on the derived interface...)

							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