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
_______________________________________________ Wikidata-tech mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
