lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane James Vaucher <vauch...@cirano.qc.ca>
Subject Re: DocumentWriter, StopFilter should use HashMap... (patch)
Date Sun, 14 Mar 2004 20:23:22 GMT
Back from a weeks' vacation, so this reply is a little late, maybe out of
order as well ;). Comment inline:

On Tue, 9 Mar 2004, Kevin A. Burton wrote:

> Doug Cutting wrote:
>
> > Erik Hatcher wrote:
> >
> >> Well, one issue you didn't consider is changing a public method
> >> signature.  I will make this change, but leave the Hashtable
> >> signature method there.  I suppose we could change the signature to
> >> use a Map instead, but I believe there are some issues with doing
> >> something like this if you do not recompile your own source code
> >> against a new Lucene JAR.... so I will simply provide another
> >> signature too.
> >
> >
> > This would no longer compile with the change Kevin proposes.
> >
> > To make things back-compatible we must:
> >
> > 1. Keep but deprectate StopFilter(Hashtable) constructor;
> > 2. Keep but deprecate StopFilter.makeStopTable(String[]);
> > 3. Add a new constructor: StopFilter(HashMap);
> > 4. Add a new method: StopFilter.makeStopMap(String[]);

Why impose implementation details in the constructor? Shouldn't the
constructor use a Map (not a HashMap), a Set, or a String array?

sv

> >
> > Does that make sense?
> >
> This patch and attachment take care of this problem...
>
> It does make this class more complex than it needs to be... but 1/2 of
> the methods are deprecated.
>
> Kevin
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message