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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
