> >> 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!"
:-) > > 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. I meant it this way, but you are right, to keep backwards compatibility, you have to do some dirty tricks :) Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
