daniel added a comment. In https://phabricator.wikimedia.org/T118860#1818705, @JeroenDeDauw wrote:
> 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: daniel Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
