This actually looks a lot like a ListMultimapBinder to me. :)
Regardless, I think it's potentially a cool idea, though I'm not sure
it's vastly superior (for dealing with edge-cases) than.
Multibinder mb = Multibinder.create(binder(), Foo.class);
...
//elsehwere
@Provides SortedSet<Foo> sortedListOfFoo(Set<Foo> foos) {
ImmutableSortedSet.copyOf(MY_SORT_COMPARATOR, food);
}
except for maybe visibility or edge-case performance considerations, or
where you need to somehow hide the visibility of Set<Foo>. Maybe the
visibility concern is enough reason to support this... but I wonder
about the behavior of overloaded priorities. :/
I think a simple list is impossible without having to have implicit
strategies for resolving those priorities - a ListMultimapBinder could
work though.
c.
On 31 Mar 2014, at 9:50, Tavian Barnes wrote:
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.
Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: [email protected] :::: mobile: +1 (646) 807-9839
--
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.
