Thanks for raising this Grant. My feeling is we can stick with an interface here, and mark it @experimental.
This is a very-low-level-very-expert API. Most users will use the "sugar" field impls (TextField, BinaryField, NumericField, etc.). Expert users will build their own FieldType and pass that to Field. Waaay expert users will skip our "user-space" Document/Field/FieldType entirely and code directly to this low level minimal indexing API. For example maybe their app sucks streamed bytes off a socket, parses out fields and immediately hands that data off to IndexWriter for indexing (never making FieldTypes/Fields/Documents). So I think such way-expert users can handle hard breaks on the API, and would likely want to see the hard break so they know they're something to fix / new to add to indexing. Mike McCandless http://blog.mikemccandless.com On Mon, Oct 24, 2011 at 10:02 AM, Grant Ingersoll <gsing...@apache.org> wrote: > > On Oct 24, 2011, at 9:56 AM, Robert Muir wrote: > >> On Mon, Oct 24, 2011 at 9:52 AM, Grant Ingersoll <gsing...@apache.org> wrote: >>> Hi, >>> >>> I was perusing trunk code on the way back from Eurocon and noticed the new >>> FieldType stuff has some interfaces in it. In the past we've tried to >>> stick to interfaces for only simple ones (i.e. one or two methods that >>> aren't likely to change at all) and instead used abstract classes for >>> bigger classes that may be subject to change more often. >> >> I think its good you brought this up Grant. >> >> I wanted to mention this: as far as interfaces versus abstract >> classes, in my opinion Lucene was under a false sense of security >> before thinking that abstract classes actually solve these back compat >> problems. >> In fact they can create serious problems like >> https://issues.apache.org/jira/browse/LUCENE-2828. In other words, if >> someone writes a delegator over an abstract class, its asking for >> trouble. >> On the other hand, delegators over interfaces are safe because they >> (and we) get a compile-time break for the new methods. > > Good point. Basically, going down this line, are we saying that we would > still allow new methods on minor versions on Interfaces? My personal take is > that if we do, we primarily just need to communicate it ahead of time. > Ideally, at least one release ahead, but maybe it is just an email. We just > want to avoid surprises for people where possible. > > -Grant > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
