On Oct 24, 2011, at 1:01 PM, Michael McCandless wrote: > 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.
:-) We thought the same of Fieldable once upon a time! At any rate, +1 on all of this. I think we are much more sane about this stuff now! > > 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 > -------------------------------------------- Grant Ingersoll http://www.lucidimagination.com
