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.

Reply via email to