thiemowmde added a comment. > What would be the name for all EntityTerms (in all languages) then?
No name. In my proposal, this is an associative array of language code => EntityTerms objects. Note that the array key is optional, it repeats the base language from the EntityTerms object. That base language is redundant in cases where the Term objects inside the EntityTerms object are all of the same language, but relevant when dealing with language fallbacks and such. > if [...] Fingerprint was just removed, there probably should be a dedicated > MultiTerm (AliasesGroup) class. This is more or less what I propose here, with two small additions: - The class I'm proposing does contain all the aliases in one language (what is called AliasesGroup now and what you call MultiTerm) plus one label and one description in the same language. - All elements (the label, the description and all aliases) are Term objects. Note that this also solves this issue <https://github.com/wmde/WikibaseDataModel/pull/272#discussion_r23175733> which needs further refactoring of the fallback classes anyway. > fallacy [...] workflow smell [...] existing users [...] There is one question I can't get out of my head: What made the deprecation of all the existing term related methods in Entity so different from the proposed deprecation of Fingerprint? Or the deprecation of the newEmpty methods, where we had the exact same discussion? Since when is backwards compatibility across versions a dealbreaker and why? It wasn't that important half a year ago. What changed? > not useful for a particular type of tasks. Fingerprint is barely useful for any task. I re-checked now and we type hint against Fingerprint in methods in 10 classes outside of tests and outside of DataModel: - FingerprintView: Misuse of Fingerprint, what it really needs is an EntityTermsForLanguage object for a single language. - 3 ChangeOp classes: Same, needs one language only. - 4 FingerprintValidator classes: Can easily be refactored to use a set of EntityTerms objects instead of a Fingerprint. From what I see this would even allow for further refactoring, like restricting the set of EntityTerms objects instead of providing the full Fingerprint and a list of languages. - EntitySearchTextGenerator and TermSqlIndex: Both are for indexing, both need all terms in all languages anyway, so neither nor is better, but very easy to refactor. That's it. > This can involve removing concepts that where inappropriately introduced > [...] And it can involve replacing objects and interfaces with new ones [...] > Given this, I'm -2 to this proposal as a whole. This confuses me. So you are ok with every detail in this proposal but not with the proposal as a whole? > I'm concerned about the name. All your arguments about the name are valid (especially the fact that other entities will need other combinations of terms), even if they equally apply to Fingerprint (plus all the other arguments already given, like not even being a fingerprint as you can see when looking at the FingerprintValidator classes). Please suggest a better naming scheme or architecture (e.g. the https://phabricator.wikimedia.org/T78286 proposal or similar) that suits these use cases. 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: thiemowmde 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
