I really recommend looking at some of the discussion near the end of LUCENE-2308. The role of EnumSet and the opinions on its use have been put forward there.
On Sat, Oct 22, 2011 at 3:32 AM, Adnan Duric <[email protected]> wrote: > Fair enough. I'd just like to get some opinions on using EnumSet instead of > the bit field in the ctor. So instead of having > > new FieldType(INDEXED | STORED) > > we wrap the options in an EnumSet, > > new FieldType(EnumSet.of(INDEXED, STORED)) > > The obvious advantage is that we don't need to explicitly set the option > members in FieldType, so no binary logic. > > > Regards, > > > Adnan > > > > On Thu, Oct 20, 2011 at 9:24 PM, Chris Male <[email protected]> wrote: > >> Good question. I think FieldType should still require an explicit >> parameter. If we then want to build a sugar StoredFieldType class, well >> then thats fine, but FieldType should layout clearly what values can be >> set. >> >> >> On Fri, Oct 21, 2011 at 2:11 PM, Adnan Duric <[email protected]> wrote: >> >>> That could work, but what happens when the user doesn't want indexing, >>> ie, indexed = false? I guess the IndexOptions argument could be ignored if >>> no indexing is taking place, but then we are forcing the user to enter a >>> dummy parameter. >>> >>> >>> On Thu, Oct 20, 2011 at 8:52 PM, Chris Male <[email protected]> wrote: >>> >>>> I really favour sticking to the existing enum and don't think we should >>>> unravel them into int flags for the reasons already put forward. >>>> >>>> Having thought about my original concern, I think its best we don't make >>>> it an optional argument, we should force users to specify what IndexOptions >>>> they want explicitly. >>>> >>>> On Fri, Oct 21, 2011 at 1:42 PM, Adnan Duric <[email protected]> wrote: >>>> >>>>> We can pass an enum member individually (DOCS_ONLY, DOCS_AND_FREQS...) >>>>> to the ctor to prevent inconsistencies. This way we would have the same >>>>> number of extra arguments as splitting them, and no complex pair checking >>>>> between them. >>>>> >>>>> >>>>> On Thu, Oct 20, 2011 at 6:40 PM, Simon Willnauer < >>>>> [email protected]> wrote: >>>>> >>>>>> On Thu, Oct 20, 2011 at 10:35 PM, Robert Muir <[email protected]> >>>>>> wrote: >>>>>> > On Thu, Oct 20, 2011 at 8:16 PM, Michael McCandless >>>>>> > <[email protected]> wrote: >>>>>> > >>>>>> >> We'd need checking in FT's ctor to catch wrong pairings, eg you >>>>>> cannot >>>>>> >> turn ont POSITIONS unless you also turn on FREQS, and at least DOCS >>>>>> >> must be set if INDEXED is set. >>>>>> >> >>>>>> > >>>>>> > What is the problem with the enum? it prevents these >>>>>> inconsistencies... >>>>>> +1 to stick to enums here! >>>>>> >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > lucidimagination.com >>>>>> > >>>>>> > >>>>>> --------------------------------------------------------------------- >>>>>> > To unsubscribe, e-mail: [email protected] >>>>>> > For additional commands, e-mail: [email protected] >>>>>> > >>>>>> > >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Chris Male | Software Developer | DutchWorks | www.dutchworks.nl >>>> >>> >>> >> >> >> -- >> Chris Male | Software Developer | DutchWorks | www.dutchworks.nl >> > > -- Chris Male | Software Developer | DutchWorks | www.dutchworks.nl
