JeroenDeDauw added a comment. Thanks all for outlining your thoughts on the subject.
I have to take issue with the basic approach taken here. It's the classical - I need some code that solves this use case nice - There already is code that deals with the relevant subject, so I can use it - Actually, it does not work well for me, and would be better in a somewhat different form - We should change the code into a more suitable form The fallacy here is thinking that because code is not suited to a specific use case, it should be changed. Instead one can write new code that handles this use case well. This way existing users of the code are not affected. Changing the responsibility of code after it's established is a workflow smell, often done without a real need for it. In big systems it is typically also not possible to have a single good representation for a concept, since the interpretation of this concept is differs subtly between contexts, making it harmful to strive for one. I can certainly see how you might not want to organize the data into the structure of a Fingerprint in a UI, and how there might be a more suitable organization there. Likewise I can see the use of having an object that collects terms for a specific language, and an interface returning such an object. I don't object at all against introducing such new code, providing it is well designed etc. And in fact I much prefer this over existing code, be it Fingerprint or something else, being used for something it is not designed for. What I object against is changing or removing code that is serving existing users well, because it is not useful for a particular type of tasks. We can address issues for individual use cases or types of tasks without having to discuss if they are more important than another set of use cases. This can involve removing concepts that where inappropriately introduced somewhere, which seems to be what Henning is mostly concerned about. And it can involve replacing objects and interfaces with new ones that are more suitable for particular use cases, which is part of what Thiemo is suggesting. Given this, I'm -2 to this proposal as a whole. This does not mean I disagree with the motivations outlined, or have a problem with things such as "EntityTerms" being created. I hope I've made it clear that I see argumentation about why some specific use case is important or why some other one is not is besides the point, and is not going to make my change my position. TASK DETAIL https://phabricator.wikimedia.org/T87237 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: Snaterlicious, adrianheine, Lydia_Pintscher, JeroenDeDauw, Aklapper, thiemowmde, Wikidata-bugs, aude _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
