Hi Chris, Thanks for the feedback. If you want to create an issue in JIRA, I'd be happy to contribute a patch to convert the FieldType constructor to bit flags. How would you want to handle the IndexOptions enum?
Regards, Adnan On Tue, Oct 18, 2011 at 9:03 PM, Chris Male <[email protected]> wrote: > Hi, > > I agree with pretty much everything Mike says. When I get round to it I > will make a patch for converting FieldType over to int bit flags. > > I also like the idea of having strongly typed sugar classes for the various > FieldTypes. > > Just a couple of things: > > This means that the IndexableField classes such as TextField, NumericField >> and the like would not be needed at all, and would be replaced by FieldType >> classes like TextType and NumericType for example; with only one constructor >> instead of several. Also, at that point, Field must be declared final. >> > > TextField doesn't really serve any purpose other than typing its true, but > NumericField and BinaryField do. They control what values can be used and > how they are converted to a tokenStream (well, BinaryField will do this in > the future). So we can't remove them. > > >> > This way, the FieldType class is no longer needed, the IndexableField >>> type >>> > classes don't need to mutate anything, and, in the end, are >>> instantiated the >>> > same way. >>> >> > Aren't we always going to need FieldType? Sure we can make some assumptions > about the likely combination of properties that will be set, but we > shouldn't box ourselves in. Today FieldType consists of just boolean > parameters, but there has also been discussion around moving other things > like NumericField DataType and IndexDocValues properties there too. I like > having an easy way for users to do common scenarios, but I also feel one of > the motivations for the changes we made to Field/FieldType recently is to > give people greater freedom. > > Cheers! > > -- > Chris Male | Software Developer | DutchWorks | www.dutchworks.nl >
