Comments on Application IDL

Pedro Szekely ([email protected])
Thu, 15 Dec 1994 11:12:17 PST

Looks like we are cooking now. This looks good. Here are my
comments, mostly questions.

Did you look at the ir.idl file that comes with orbline. It is very
similar to yours.

1) I am not quite sure I understand itype. It seems that there is a
possibility to store a value. I think that the application IDL will
not store values, so there is no need to allow for that. Why isn't
the type just the enumeration of all possible types supported in IDL?

2) Convention issue. Should we name all the enumerations with all
caps?

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?

I wonder if there is some fancy optimization going on for sequences
that we would not have if we use iterators to completely hide the
representation of information that is stored in some form of
collection.

Pedro Szekely
USC/ISI, 4676 Admiralty Way, Marina del Rey, CA 90292
Phone: 310/822-1511, Fax: 310/823-6714
URL: http://www.isi.edu/isd/HUMANOID-HOME.html