I've read the discussion and EnumSet was mentioned but nobody really had an opinion on it. I guess I can put forward a patch with EnumSet and then wait and see.
On Fri, Oct 21, 2011 at 8:58 PM, Chris Male <[email protected]> wrote: > 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 >
