>> 2. Generics' utility is not limited to collections, we use it for >> type-safe index fields storage/querying for example. >> Define field: >> FieldInfo<EmployerCategory> EMPLOYER_CATEGORY = >> field(ENUM(EmployerCategory.class), INDEX); >> Store it: >> add(vacancy.getEmployerCategory(), EMPLOYER_CATEGORY); >> Query it: >> return FilterTerm(EMPLOYER_CATEGORY, complementOf(EnumSet.of(AGENCY))); >> >> any field access is type-checked at compile time and happily >> autocompletes in IDE > > You are right, too, but this change needs modifications in the Lucene API. I > think this is a later step. I'm simply suggesting it, like for 2010 :) Vigorously preserving back-compatibility really takes the momentum out of Lucene development effort, in my opinion. I'd be much happier to rewrite half of my code each major release than limp along with some ugly stuff just for the sake of someone dropping in a new lucene jar into their mess and exclaiming - "Wow! It still works!" But excuse me, I wasn't going to stir up old arguments.
> Another step to Java 1.5 would be the use of Enum instead of Parameter, but > this cannot be done easily without breaking backwards compatibility. A first > approach would be to subclass "Parameter" to be instanceof "Enum". This can > be done by deprecating the old methods, that map to Enum methods (but I > think there are none). In short: replace the Parameter class by "Parameter > extends Enum". In Lucene 4.0, the Parameter class disappears and we have > nice clean enumeration types, which are also syntactical sugar :) You can't extend Enum in any way other from writing "public enum Parameter .. blah-blah" without resorting to really dirty tricks. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785
