There's no real benefit except for perhaps discovery. I hit this code while pressing F4 in eclipse on FilterCodec. I'm not sure that I'd do the same for StoredFieldsFormat, but perhaps I just need to get used to it. It's like how I discover Analyzers, I search for Analyzer extensions, not TokenStreams/Filter.
But it's not critical, just thought that as a Codec, it's pretty generic. I'm fine if we rename it only when the back-compat cannot be maintained any longer. Shai On Thu, Nov 15, 2012 at 1:17 PM, Adrien Grand <jpou...@gmail.com> wrote: > Hi Shai, > > On Thu, Nov 15, 2012 at 11:39 AM, Shai Erera <ser...@gmail.com> wrote: >> >> what if we made it a non-test class, which takes any Codec to wrap (i.e. >> not default to Lucene41Codec)? >> > > What would be the benefits of having this class vs. extending FilterCodec? > > >> While at that, should CompressingStoredFieldsFormat be named >> CompressingStoredFieldsFormat41 or something like that, preparing it for >> future changes? Or ... or we can add the version to the name only when it's >> actually changed ... >> > > Given that this class is @lucene.experimental, I think we could do the > following when modifying the file format: > - if backward compatibility is easy to maintain, just bump the version > number > - otherwise copy all the logic to Lucene41StoredFieldsFormat (instead of > making Lucene41StoredFieldsFormat extend CompressingStoredFieldsFormat) and > we can then change anything we want in CompressingStoredFieldsFormat > without worrying about backward compatibility. > > -- > Adrien >
