I think this is the last message from you that I have not replied yet.
-------------------------------------------------------------------
> >
> > 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.
>
> 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.
>
Ok, sounds good.
-------------------------------------------------------------------
> >
> > 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.
>
So the ivalue is a way to store the "nested" types for things like sequence.
I didn't understant that, and I am not sure I understand it yet. I trust you
that it is correct, and perhaps a bit of extra documentation would be helpful.
-------------------------------------------------------------------
> >
> > 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.
>
Ok with me. Comments from anyone else?
-------------------------------------------------------------------
> >
> > 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.
>
Did we discuss this enough in the previous messages? I favor iterators.
-------------------------------------------------------------------
> >
> > 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.
>
I see. Sounds good to me.
-------------------------------------------------------------------
NEW ISSUE.
The access methods for iinterface need parameters to spacify whether you want
to get back the inherited attributes too.
Say you have the following interfaces:
interface A {
attribute int x;
void m (in int p);
};
interface B : A {
attribute int y;
void n (in int p);
};
Suppose that iinterface has a method called attr_iter that returns an iterator
to iterate over all attributes of an interface. attr_iter should have the
following signature:
IAttr_Iter attr_iter (in bool inherit, in int num_levels);
So, say b is a pointer to the iinterface for B:
IAttr_Iter iter = b-> attr_iter (FALSE, 0)
// the iterator would produce an iattr for x.
IAttr_Iter iter = b-> attr_iter (TRUE, 1)
// the iterator would produce iattr for both x an y.
I am not sure if it is necessary to have the num_levels parameter. Also, I am
not sure whether bool shoould be spelled differently. However, we need some
way to allow clients to ask for the inherited stuff.
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