lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Ganyo <>
Subject Re: getAllFieldNames diffs
Date Wed, 13 Nov 2002 15:52:12 GMT
Now that we've committed to Java 2, I would not be opposed to removing 
Enumeration references... or at least deprecating them in favor of 
newer-style methods.


P.S. A side note on the performance item mentioned below:  As the 
Collection classes are interfaces, it is entirely possible to back a 
Collection with a lazy-read pattern of access.  No Iterators are 
required for this behavior either.

Peter Mularien wrote:

> 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.
> 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:

Brain: Pinky, are you pondering what I’m pondering?
Pinky: I think so, Brain, but calling it a pu-pu platter? Huh, what were 
they thinking?

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message