Issue 3271: semantics of boolean iterator.next(out thing) ... (zz-collection) Source: (Mr. Philip Lijnzaad, p.lijnzaad(at)med.uu.nl) Nature: Uncategorized Issue Severity: Summary: 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 PropertyService says: 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 the iterator. 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 retrieved. (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. Resolution: Revised Text: Actions taken: February 4, 2000: received issue Discussion: End of Annotations:===== Date: Fri, 4 Feb 2000 12:47:03 GMT Message-Id: <200002041247.MAA09561@o2-3.ebi.ac.uk> X-Authentication-Warning: o2-3.ebi.ac.uk: lijnzaad set sender to lijnzaad@ebi.ac.uk using -f From: Philip Lijnzaad To: issues@omg.org Subject: semantics of boolean iterator.next(out thing) ... Reply-to: lijnzaad@ebi.ac.uk Content-Type: text X-UIDL: (PX!!kid!!g`De9p2O!! Dear issues@omg.org, 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 PropertyService says: 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 the iterator. 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 retrieved. (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. Philip Lijnzaad -- With 3 digits to the finger, why do they tell me digital is binary? ----------------------------------------------------------------------------- Philip Lijnzaad, lijnzaad@ebi.ac.uk | European Bioinformatics Institute,rm A2-24 +44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53 Date: Wed, 21 Mar 2001 10:57:02 +1000 (EST) From: Michi Henning To: Juergen Boldt cc: issues@emerald.omg.org Subject: Re: Lost issues In-Reply-To: <4.2.0.58.20010320104951.00a86ca0@emerald.omg.org> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :BJe9a1K!!,[8e9=SL!! On Tue, 20 Mar 2001, Juergen Boldt wrote: > Hello all, > > URL http://cgi.omg.org/issues/issues.html > contains links to issues which have not been assigned to R/FTFs > because of > a couple of reasons: > ..to name a few... > a) The RTF/FTF has expired and should be re-chartered > b) The RTF/FTF has expired and will never be re-chartered again > (several > reasons why are possible) > c) I just didn't know what RTF/FTF would be responsible for an issue > submitted.. > d) There appear to be no RTFs for most of the CORBAservices > e) Nobody knew about this issues archive > > With your help some of those issues could be resolved (by assigning > some of > those issues to active RTFs/FTFs or by rechartering some of the > expired > RTFs...) Here are some proposals: Issue 184: Close no change. I don't understand the question Issue 468: Close. The issue is empty. Issue 493: Close no change. It doesn't because the submitters decided that it wouldn't. Issue 498: From what I can recall, this refers to name equivalence in the Naming Service. INS has cleaned this, so close it. Issue 961: Move to http://cgi.omg.org/issues/event-rtf.html Issue 2347: Close. This was fixed by INS. Issue 2972: Move to http::/cgi.omg.org/issues/relationship-rtf.html Issue 3003: Close. Issue 3271: Close no change. Historically, iterators in the various specs are a total mess, and all of them, without exception, get it wrong :-( I'm afraid we have to live with the resulting inconsistencies. Issue 4216: Should probably be reassigned to Core RTF? Issues 284, 546, 547, 548, 549, 550, 558, 559, 560, 561, 562, 4225: We need a trader RTF for those. The remaining open issues also will require formation of RTFs. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi