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
