>
> 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.
>
Let's see if I understand where we are.
I think we have agreed that we need add methods in the main interface
definitions to add elements, and have a handle to do global error checking and
other kinds of book-keeping.
We are debating now the issue of using sequences or iterators to access
multivalued elements. We currently have two possibilities:
1- expose the attribute as a sequence, so that clients can access all the
elements from the sequence. The problem is that clients should not add
elements to the sequence itself, but call the add methods on the objects that
contain the sequence.
2- don't expose the attribute as a sequence, but rather use an iterator.
The disadvantage of 2- is that we need to create an iterator class for each
kind ok interface that can be stored in some kind of collection.
JK says it is bad to have all these extra collection classes. I don't see why
this is bad. Is it inefficient? Is it a pain to write?
Since we don't have that many different classes of objects, I think that there
won't really be a huge proliferation of iterator classes. I think the macro
idea works ok (saves typing), and allows us to have all the iterators we need.
I must confess that I like the idea of iterators because it completely hides
the representation of the sequences. Also iterators provide added
flexibility. I will write another message illustrating this. Also, the fewer
CORBA/IDL primitives that we use, the easier it will be to make our
implementation independent from CORBA vendors.
To summarize, are we agreeing to use iterators rather than sequences?
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