On Thu, May 13, 2010 at 12:16 PM, John Hjelmstad <[email protected]> wrote:
> On Thu, May 13, 2010 at 12:01 PM, Paul Lindner <[email protected] > >wrote: > > > hrm.. > > > > Due to the ordered magic of ImmutableSet we do get things injected in the > > correct order: > > > > I sort of figured that to be the case, though I'm still a bit loath for > important behavior to depend on quasi-magic (Guice :)) combined with what's > arguably an accident of implementation details rather than a prescribed > API. Okay, let's change the signature to List<String> so it's explicit then (as you describe in the paragraph below). This also allows one to override the provider in another module using Guice 2.0 Override mechanisms. In our particular case, we'd be reasonably well-served by simply @Inject'ing > a List<String> into FeatureRegistry constructed via the two Sets > (String.split and Set<..> extended), guaranteeing at least relative order > of > those two (and order of the features provided by the comma-delimited > String. > > Since this gives users flexibility to guarantee order when they _really_ > need to do so, and to perform one-time extensions past that, this seems > generally reasonable, if not totally ideal. > > > > > > > So I believe this is safe to apply as-is. Still it seems like there > should > > be a better way to do this. The use cases I can see that we might need > to > > address: > > > > * Override default features (works by insuring that we add user features > > last). > > * Removing features from the default. Trickier... Currently you have to > > copy features.txt and remove the ones you don't want. Might make sense > to > > have a blacklist of features you don't want to support. > > > > The former case here seems pretty common; the latter isn't possible today, > so I'd bucket it as a "new feature" once it's demanded. Okay. > Agreed that Set/Map injection via contributor style is a laudable goal, and > I appreciate you/we are moving toward it. But I'm a bit loath to invent > some > kind of ordering-fu (Comparator for instance) as an especially-magical > implementation requirement for ordering... hmm... > > Another simpler option is to have separate sets for each rewriter phase, ala Apache Httpd modules http://httpd.apache.org/docs/2.0/developer/request.html This could be done with multibindings or AOP pointcuts...
