lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Ganyo <scott.ga...@etapestry.com>
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.

Scott

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


-- 
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:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message