> Actually though - how are we supposed to get back there? I don't think > its as simple as just not removing the deprecated API's. Doesn't even > seem close to that simple. Its another nightmare. It would have to be > some serious wins to go through that pain starting at a 3.0 release > wouldn't it? We just had a ton of people switch. We would have to > deprecate a bunch of stuff. Hard to imagine wanting to switch now - the > new API is certainly not that bad.
It is not bad, only harder to understand (for some people). As noted in my previous mail, we could start the same discussion like with the Collectors: Should we provide some easy to use FieldComparators, that can be used as a starting point? Maybe someone that looks like the comparators used for byte/int/short and so on, but has an abstract method getComparable(IndexReader reader, int doc) [relative to current reader] that returns an Comparable<T>. All other methods and Arrays use the datatype Comparable<T> and implement just the compare functions inner slot and botton. Or maybe another wrapper that takes an java.lang.Comparator<T> and a method T getSortValue(IndexReader reader, int doc) and implements the comparison. We had something like this in the old API, too. It could be implemented by a wrapper with this easy API. These wrapper classes may be lot of slower than native FieldComparators directly working on the native types, but would help to create simple sorting for things like geo-distances, where the calculation of the field values/Comparable<T> takes most time. So some easy-access or sample comparators like this in contrib would be fine. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
