mkroetzsch added a comment.
I don't want to detail every bit here, but it should be clear that one can
easily eliminate the dependency to $db in the formatter code. The Sites object
I mentioned is an example. It is *not* static in our implementation. You can
make it an interface. You can inject Sites (or a mocked version of it) for
testing -- this is what we do. The only dependency you will retain is that the
formatting code, or some code that calls the formatting code, must know where
to get the URL from.
All of this will work in any "sane" architecture -- I don't see where you need
a role manager for this. In particular, you can always pull out dependencies by
injecting interface-based objects instead, and this has nothing to do with how
you represent the "derived data" in memory using objects. The role-based
approach discussed here simply seems to be a generalised version of this
pattern, with a one-solution-fits-all interface ("Role") instead of
task-specific interfaces ("Sites" etc.). The reason why I am not convinced by
this here is that the tasks at hand are quite diverse and refer to different
objects. So for any particular object (such as SiteLink) you might not have
many possible roles available, probably just one, and in such a situation the
complexity of the general solution might be avoidable.
Maybe it's clearer if I say it in terms of the simpler "hash map of additional
data" approach that @adrianheine mentioned: it seems to me you are adding such
hashmaps to all objects (using a somewhat complicated way to encode the
hashmap), just to have one or two entries per object in the end. In such a
case, rather than using a hashmap, you would better use a member variable that
can be null if the additional data is not there.
TASK DETAIL
https://phabricator.wikimedia.org/T118860
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: mkroetzsch
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki,
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
