I forgot to mention, I have a task for 3.0: https://issues.apache.org/jira/browse/LUCENE-1857
This will add more type safety and then maybe the ctors can be made public again and the static methods be deprecated/removed. Same for NumericField and NumericTokenStream. I will do this after commiting the AttributeSource generics together and many other generics that are important for a clear (public) Lucene API. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Wednesday, September 23, 2009 1:42 AM > To: java-dev@lucene.apache.org > Subject: RE: NumericRangeQuery "static" constructors > > It is just for some type safety (with generics it would be better to > handle). The problem is, that overloading the ctor with long, int, float, > double makes it really hard to choose the right one (you miss an L when > passing anumber and get an int range query and so on, especially when Java > 5's autoboxing is on). With the static "ctor" methods, it is clear what > you > create (and conforms to API of NumericField). > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -----Original Message----- > > From: Grant Ingersoll [mailto:gsing...@apache.org] > > Sent: Wednesday, September 23, 2009 1:33 AM > > To: java-dev@lucene.apache.org > > Subject: NumericRangeQuery "static" constructors > > > > I was wondering what was the reason for the "static" constructors on > > the NumericRangeQuery? I don't get the point of a static method call > > that simply passes through to a normal constructor. Are people > > somehow magically more capable of discerning the meaning of a static > > method than simply calling new NumericRangeQuery() and passing in the > > same parameters? > > > > -Grant > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
