Re: Comments on Application IDL
Jayakumar Muthukumarasamy ([email protected])
Fri, 16 Dec 1994 12:40:54 -0500 (EST)
>
>
>
> 3) I am not sure it is a good idea to define the interfaces with
> sequences. Here is an example of what I mean. For example,
> iinterface is defined as follows:
>
> interface iinterface {
> attribute sequence<string> typedefs;
> attribute sequence<string> constants;
> attribute sequence<iattribute> attributes;
> attribute sequence<iexception> exceptions;
> attribute sequence<imethod> methods;
>
> DEFINE_SEQUENCE_OPS(typedefs, string);
> DEFINE_SEQUENCE_OPS(constants, string);
> DEFINE_SEQUENCE_OPS(attributes, iattribute);
> DEFINE_SEQUENCE_OPS(exceptions, iexception);
> DEFINE_SEQUENCE_OPS(methods, imethod);
> };
>
> Suppose I am working in the design environment and I have a partially
> constructed interface with several attributes defined already. If I
> want to add a new attribute I create a new instance of attribute, and
> call one of the sequence methods to add it to the sequence of
> attributes. I assume that by adding it to the sequence, the new
> attribute actually becomes part of the interface (ie. there is no need
> to store the sequence back into the iinterface).
>
> The main concern is the following. Suppose that we wanted to check
> that the new attribute is compatible with information in the methods.
> This could happen once we extend the IDL model to store dependencies
> between methods, attributes, etc. The method that adds elements to
> the sequence does not have a handle to get to other parts of the
> interface.
>
> Another way of doing it is as follows:
>
> interface iinterface {
> readonly attribute sequence<string> typedefs;
> readonly attribute sequence<string> constants;
> readonly attribute sequence<iattribute> attributes;
> readonly attribute sequence<iexception> exceptions;
> readonly attribute sequence<imethod> methods;
>
> void add_attribute (in iattribute);
> etc.
>
> Also, the methods to change the sequence are disabled. The
> add_attribute methods has access to all information in the iinterface,
> and so can do global checking with the other info in the iinterface.
>
> What we did in the presentation IDL is to define all things that are
> sets with 3 methods:
>
> void add_xxx (in yyy);
> void remove_xxx (in yyy);
> XXX_Iter get_xxx_iter ();
>
> By doing this, the methods can do global maintenance on other data
> structures. Also, we don't expose the internal representation
> collection elements.
>
> What do you think?
>
A correction:
Please ignore my comment for this section in my previous mail. The
macro "DEFINE_SEQUENCE_OPS" adds operations to the interface to
add/remove/change entries to a sequence. So, it is still functionally similar
to the functions you suggest. Ofcourse, with sequences being exposed in the
interface, it is possible to get a reference to a sequence, and add elements
to the sequence, thereby bypassing the standard functions. We can avoid this,
by hiding the attribute sequence from the interface and have it only in the
implementation instead. This being the case, we will need the iterators that
you suggested to access elements in a sequence. This brings us to the problem
of creating a new iterator interface for each new sequence. May be we
could fake this using macros?
e.g.
#define DEFINE_ITERATOR(type) \
interface type_ ## _iterator { \
type _next() \
type _prev() \
... \
} \
#define Iterator(type) type_ ## _iterator
and, for every sequence we define, we should take care to define its
iterator by invoking the macro. e.g.
DEFINE_ITERATOR(int) /* iterator for a collection of ints */
DEFINE_ITERATOR(float) /* iterator for a collection of floats */
DEFINE_ITERATOR(iinterface) /* iterator for a collection of iinterface */
Does this sounds OK? Also, when it comes to protecting, should we protect
just sequences, or just every attribute.
-jk