daniel added a comment. @JeroenDeDauw You can also see it this way: feature parity is for model+serializer. If we move all the options and modes into the model, we need something to build the "output model" from the "core model", and that converter thing would need to do all the things described in the blockers.
Going this way, feature parity would be blocked on creating the "output model" and the corresponding converter, which would in turn be blocked on all the features mentioned here. So you'd add at least two more blockers, and the need for a few additional data structures. This does not strike me as a good thing. Sure, code that relies on modes and switches is annoying. And serializers should be dumb. But if upholding these principles 100% causes a lot of overhead, we should probably go for a balance point closer to the energetic minimum... TASK DETAIL https://phabricator.wikimedia.org/T73170 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: JeroenDeDauw, thiemowmde, Bene, Wikidata-bugs, Tobi_WMDE_SW, JanZerebecki, adrianheine, Lydia_Pintscher, daniel, aude _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
