lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: getAllFieldNames diffs
Date Wed, 13 Nov 2002 17:24:24 GMT
Scott Ganyo wrote:
> 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.

The javadoc for Enumeration says:

"The functionality of this interface is duplicated by the Iterator 
interface. In addition, Iterator adds an optional remove operation, and 
has shorter method names. New implementations should consider using 
Iterator in preference to Enumeration."

We should not make incompatible changes to frequently used parts of the 
API just to clean things up.  That's a bad tradeoff, especially if we're 
not adding any new functionality.

I think we should, as suggested above, leave Enumerations as they are, 
and start using Collections in new code, when appropriate.


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

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

View raw message