Legacy Issue Number: 3271
Source: med.uu.nl ( Philip Lijnzaad)
here's a thing that has been bugging me for a while: the description of the
semantics of the iterators in some of the CORBA Services seems to be unclear
and inconsistent. They falls into two categories:
Semantics A: returned value is relevant for the next invocation
The next_one() operation returns TRUE if an item exists at the current
position in the iterator ... A return of FALSE signifies no more items in
Interoperable Naming Service says:
The next_one() operation returns the next binding. It returns TRUE if it is
returning a binding, FALSE if there are no more bindings to retrieve. If
next_one() returns FALSE, the returned Binding is indeterminate.
(the intention behind this is actually different, see below, as Michi
Henning pointed out to me)
The Trader Service (e.g. OfferIdIterator) says:
The next_n() operations returns TRUE if there are further offer identifiers
to be extracted from the iterator. It returns FALSE if there are no
further offer identifiers to be extracted.
(this is also clear, even though I don't think this is the rigth design).
Semantics B: returned value is relevant for the past invocation:
The Collection Service:
retrieve_element_set_to_next() returns TRUE if an element has been
(This is really clear)
In case A, a client always has to check whether s/he got something useful in
the out parameter (since a FALSE return only says something about the
subsequent call); this is not very elegant. In case B, a client always has to
spend a fruitles round-trip to the server to know when the iteration is
finished. This is IMO a better solution, and should preferably be adhered to
by any OMG standard.
Reported: COLL 1.0b1 — Fri, 4 Feb 2000 05:00 GMT
Updated: Wed, 11 Mar 2015 23:32 GMT