Resolving redirects and retrieving entities are two different things. Sometimes you want to do both, sometimes just one. Trying to create a general solution by adding one of them to an existing interface dedicated to the other is bound to end up being problematic, as your email illustrates. I suggest only putting them together where there is need to do so, and create new objects and interfaces based on the needs encountered there. Forcing the existing interface to know about redirects would be repeating the mistake of putting the revision id in there, though in this case it'd be worse.

Perhaps we can get around all this mess by making redirect resolution something
the interface doesn't know about? An implementation detail? The logic for
resolving redirects could be implemented in a Proxy/Wrapper that would implement
EntityRevisionLookup (and thus also EntityLookup). The logic would have to be
implemented only once, in one implementation class, that could be wrapped around
any other implementation.

>From the implementation's point of view, this is a lot more elegant, and removes
all the issues of how to fit the flag for redirect resolution into the method
signatures.

However, this means that the caller does not have control over whether redirects
are resolved or not. It would then be the responsibility of bootstrap code to
provide an instances that does, or doesn't, do redirect resolution to the
appropriate places. That's impractical, since the decisions whether redirects
should be resolved may be dynamic (e.g. depend on a parameter in an web API
call), or the caller may wish to handle redirects explicitly, by first looking
up without redirect, and then with redirect resolution, after some special
treatment.

I'm not suggesting this is the approach to take, though I disagree with the objections raised against it. First of all, it is not the caller that has the control, it is the thing configuring the object graph being used. If the decision if redirects should be resolved or not needs to happen after this configuration, then you can simply have your object require both types of lookups. This would work, though it makes clear the approach of putting this functionality in a wrapper is odd for this use case. Having a service to resolve redirects and one to look up entities would be a lot more natural.

Cheers

--
Jeroen De Dauw - http://www.bn2vs.com

Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3