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.
On the one side, interfaces are cleaner design wise, but adding new methods makes it hard for supporting back compatibility if we wish to add new methods. Abstract classes allow for back compat, but they are perhaps a bit less clean b/c they often tie an implementation to the broader API. In the past, we've been bitten by interfaces b/c let's face it, we can't predict the future (Fieldable is the most notorious -- and this stuff has a very Fieldable feel to it -- but there are others, please see the archives for past discussions.) I think in an ideal world, interfaces are kept quite compact and use use multiple of them and then you provide a base abstract class that provides most of the implementation for most people by implementing said interfaces. Logically, this doesn't always work out. An alternative is to mark it all as experimental and punt for now. In the end, I just want to make sure we have the discussion about it so that we don't find ourselves having to wait until 5.x in order to add a new method to one of these interfaces. Alternatively, perhaps we won't need to at all or perhaps we think no one other than core Lucene will implement these. Just trying to avoid past pain and headaches in the future. -Grant --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
