Just found the rest of the thread. I'll shut up now ;) sv
On Sun, 14 Mar 2004, Stephane James Vaucher wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
