On Mon, Apr 13, 2009 at 9:02 AM, Earwin Burrfoot <ear...@gmail.com> wrote:
>> I think I'd lean towards only at construction. Seems dangerous to >> allow swap in/out at some later time. > I have several points pro-runtime: > 1. We have a lot of static factory methods, it's gonna be a problem > passing plugins everywhere on creation. "We" is who here? Couldn't "they refactor their code to callback into those static factory methods? Presumably you'd pass into Lucene a "CreatesXYZComponent" instance which given a SegmentInfo (or a public'd version of it, with extensibility, etc) returns an XYZComponent. > 2. public <T extends IRP> void bindPlugin(Class<? super T> type, T > instance) is ..er.. typesafer than passing Map<Class, IRP> in > constructor. Can you make this more concrete? (I'm having trouble following... the generics). > 3. Plugins support attachment/detachment and they don't need to know > exact reason they were attached/detached for - there should be no > difference between closing a reader and removing plugin from it. But what's the use case here? Why would a SegmentReader need to detach/attach a new XYZComponent? And... why not simply open a new SegmentReader? With this change, opening a new reader can be an extremely low-cost operation since you could share already opened XYZComponents. A SegmentReader simply becomes a set of components held together. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
