I did take a look at it. The organization is confusing and it
took me quite sometime to understand it. That is the reason, I choose not
to follow it. Otherwise, it is quite similar.
>
> 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?
This will not do for the following reason. We can have sequence
of sequences i.e. sequence<sequence<int,10>>. For this we need, an
itype, otherwise, we will loose the information that the second sequence
is actually a sequence of ints. Also, consider the case where we have
a sequence within a struture or interface.
>
> 2) Convention issue. Should we name all the enumerations with all
> caps?
I usually have all-caps for "#defines", and small's for enum's.
It has been that way for no good reason. So, I am fine with this
convention too.
>
> 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.
I would agree with you completely. If we need to do error checking
then it is, as you have suggested, best to keep the method part of
the interface instead of making it part of the sequence. I will make the
appropriate changes.
>
> 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?
The only problem I have is with respect to iterators. Having an
iterator for each type of sequence, is expensive in terms of classes.
There is a very good way to do this in C++, namely templates. But,
IDL doesn't have anything equivalent to templates. We could have an
interface called Iterator that doesn the equivalent of templates, but,
I am not sure, how we should handle user defined types. any's would
be one way to handle it, but we would loose the goodness of typechecking
for user defined types. So, what do you suggest.
>
> 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.
There is really no difference between using sequences, and
iterators in terms of efficiency. The only problem is the burgeon-ing
of classes.
-jk