This is the kind of thing that could reasonably be made into an extension,
maybe I'll take a crack at it.
It would look something like this:
ListBinder<Snack> listBinder = ListBinder.create(binder(), Snack.class);
listBinder.addBindingWithPriority(0).toInstance(new Twix());
listBinder.addBindingWithPriority(1).toProvider(SnickersProvider.class);
listBinder.addBindingWithPriority(2).to(Skittles.class);
Something similar could be done to enforce ordering on interceptors (which
is probably a more important use case).
On Monday, 31 March 2014 03:56:43 UTC-4, Tim Boudreau wrote:
>
> Oh, I understand the reasoning behind it. And in the case of, for
> example, module load order, it's definitely the right approach; and for
> some parts of module loading there may be a natural order (by following the
> dependency graph).
>
> But for method interception, that's essentially the listener pattern - a
> list of things which are called repeatedly on some trigger. In that case,
> there's no getting around the fact that, at runtime, it is a list which has
> an order. If I have, say, one interceptor that logs all calls to foo() and
> another interceptor that, say, collects the number of milliseconds spent in
> that method, I probably don't want the logging included in the
> benchmarking. It would be trivial enough to add an order parameter and
> sort the interceptors by it before calling them.
>
> What happens with this sort of thing is people unknowingly depend on the
> order being stable, and wind up with very hard to track down bugs when it
> changes. I've seen that happen quite a few times. The fact that Sam says
> "We'd
> break all our servers if we [changed interceptor ordering]" suggests that
> that's exactly what's happening.
>
> I'd much rather specify an explicit ordering than depend on the good
> graces of someone not changing an order they've told me is unspecified (and
> therefore capable of changing "compatibly").
>
> For the case of set binding, yeah, the set has an undefined order; what
> I'm proposing is a way to bind a List which does, with user-supplied
> explicit ordering.
>
> You can do this yourself in an ugly way with
>
> class ListProvider implements Provider<List<T extends Ordered>> {
> private @Inject Set<T> set;
> ... copy the set contents to a list and sort it
> }
>
> but hard-coding these ordinals into the type is putting an attribute that
> ought to be part of the binding into the type.
>
> -Tim
>
>
--
You received this message because you are subscribed to the Google Groups
"google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.
