Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@apache.org Received: (qmail 75838 invoked from network); 13 Nov 2002 15:43:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Nov 2002 15:43:39 -0000 Received: (qmail 17160 invoked by uid 97); 13 Nov 2002 15:44:36 -0000 Delivered-To: qmlist-jakarta-archive-lucene-dev@jakarta.apache.org Received: (qmail 17129 invoked by uid 97); 13 Nov 2002 15:44:35 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 17116 invoked by uid 98); 13 Nov 2002 15:44:34 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DD27323.60801@deploy.com> Date: Wed, 13 Nov 2002 10:43:31 -0500 From: Peter Mularien Organization: http://www.deploy.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021107 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lucene Developers List Subject: Re: getAllFieldNames diffs References: <3DD26C95.4030503@etapestry.com> In-Reply-To: <3DD26C95.4030503@etapestry.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Well, I guess we've opened a can of worms here. (: I was voting with Clemens mostly for the argument of consistency with the rest of the Lucene code. It does seem a bit bizarre to me that we'd still be using Enumeration elsewhere in the code, but Collection in this new API, hence the "compromise" of an Iterator. So I went and did some research on the Sun web site to see if I could find any guidance there. I did locate a couple bug reports where people requested API changes of the sort that Clemens requested (Collection->Iterator or some such), here are a couple interesting bits: [ref. http://developer.java.sun.com/developer/bugParade/bugs/4357111.html, reviewer comments:] / >It is generally considered bad form to return results in the form of an >Iterator; it is greatly preferable to return a Collection. > ... >It is much easier and more efficient to >code against your API if you return the Collection rather than the Iterator. >For example, suppose your user wants to know the number of returned elements >prior to examining the elements themselves; with a Collection it's trivial, >with an Iterator, it's inefficient and painful > / / /While I don't consider this particular reviewer an authoritative source (and I did try looking in various well-traveled Java books of mine) I couldn't find anywhere else where someone seemed to take a stand one way or the other. Scott pointed out another authoritative source as I was writing this message. (: I would like to vote for the "return a Collection/Set" side for two reasons: 1. It's fairly trivial to generate an Iterator if necessary. 2. We aren't talking about returning a lot of data here, where backing the Iterator with an efficient reader pattern (as Clemens indicated) makes a lot of sense. I did appreciate Darren's suggestion about returning a Set, and I don't see any problem with returning that. So, then the question becomes, does it make sense to look at the other APIs and think about rewriting those for consistency's sake? Will submit updated diffs to the list (with Collection->Set) later today. Peter / /Scott Ganyo wrote: > +1. In general, I don't believe that returning Iterators is a good > idea. Whenever feasible, I would return a Collection instead of an > Iterator. > > Scott -- To unsubscribe, e-mail: For additional commands, e-mail: