Hey,
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