On Thu, Oct 20, 2011 at 5:23 AM, Adnan Duric <[email protected]> wrote:
> 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? > That's a good question. Forcing it to be a compulsory constructor argument is a little messy, but so is having two constructors to support defaults. This is the kind of problem that we discussed in LUCENE-2308 as Mike mentioned. Feel free to open the issue yourself :) and attach a patch which deals with it in a way you feel happy with. We can all then review it and discuss. > > > 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 >> > > -- Chris Male | Software Developer | DutchWorks | www.dutchworks.nl
