JeroenDeDauw added a comment. I find this approach very odd, do not understand why it would be a good idea, and am generally quite worried about it.
My main concern is pretty much described by the first paragraph of @mkroetzsch his first post. I've read through the replies, though found the reasoning in there to generally be either besides the point, or lacking actual depth such as "I did something like this before and it did not work well". As I've pointed out before, it makes no sense to me starting to discuss this on the premise we need one global solution for this. Looking at individual problems we need to solve and what the best solution is for those seems like a much better approach. Similarly, the need for deferred deserialization has not been demonstrated to me. I can see how it can be helpful in theory, though am missing the concrete places of where this would be, and why for each of those cases the deffered approach is best. "Trust me, I already thought about it, and came to this conclusion, no need to re-examine it" is not an acceptable starting point if you want me to reason up from it. A second concern I have is a combination of this approach ticking off several design warning boxes and me not having seen anything in this direction used or justified for a usecase like this anywhere. That by itself does not mean the approach is bad, though it certainly adds to my worry. >> That looks to me like a fancier and less understandable way of just having >> an additionalData hash on each data model object. Did I miss something? > > The names would be arbitrary, but it can be made type safe. My idea was to > use getRoleObject( $name, $type = null ) to perform an optional check against > $type. This saves the caller from writing an if check, at the cost of passing a type as string and having the role manager do the check? I think that's a bad trade-off, and certainly not big enough of a good thing to warrant the additional complexity proposed here. > (representing all data in a dumb model before generating output was suggested > by two external reviews) Those reviewers talked about having a response model that you can give to a presenter. That is very different from that you are proposing here. > where the cross-dependencies have kept us from splitting serialization code > into a separate component for a long time Huh? Splitting off the serialization code was not very hard, and not delayed by needing services such as those Markus talks about. >> When things have a conceptual dependency, it is not bad design to have a >> code dependency there as well. > > I agree, but that dependency should be as narrow as possible. That's why > "Read Models" exist. I utterly do not understand your reply to Markus here. What do read models have to do with what he wrote? > WikidataQuality has no place to put constraint violation info on Statements What makes you think it's a good idea for an extension that adds a new concept to glue it onto an object from a different context? PS: I do not think it is a good idea to start a discussion on if a particular pattern is suitable for ones usecase by listing a bunch of big names that have used the pattern in the past. Appeal to authority. TASK DETAIL https://phabricator.wikimedia.org/T118860 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw 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
