[Wikidata-bugs] [Maniphest] [Changed Project Column] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
Bene moved this task to Review on the Wikidata-Sprint-2016-02-02 workboard. TASK DETAIL https://phabricator.wikimedia.org/T126152 WORKBOARD https://phabricator.wikimedia.org/project/board/1722/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
Bene created this task. Bene added subscribers: Bene, thiemowmde, JeroenDeDauw, daniel. Bene added projects: Wikidata, Wikibase-DataModel, Wikidata-Sprint-2016-02-02. Herald added subscribers: StudiesWorld, Aklapper. TASK DESCRIPTION The current interfaces to access terms (`LabelsProvider`, `DescriptionsProvider` and `AliasesProvider`) all state in their contract: "It is not guaranteed that this method returns the original object." This is a problem because with that sentence we cannot rely on the fact that changes made to the `TermList` returned by the method are visible to the provider. We have three options so solve this issue: * We can either create a second list of interfaces called `LabelsHolder`, `DescriptionsHolder` and `AliasesHolder`. This is how we solved the issue for `Fingerprint` and `StatementList`. The disadvantages are that we get the overhead of three additional types and that we have to call the setter everytime we want to change someting. Code will always be like `$var = $obj->getFoo(); $var->setBar( 'baz' ); $obj->setFoo( $var );`. * Another option is to change the contract of the interfaces so that they always return a reference to the original object in the provider. We can then be sure that all changes are visible to the provider. However, there is no option to replace the entire object in case we want to clear the list (for example). * Third option would be to merge all the "provider" and "holder" interfaces. We than don't have the choice to provide immutable providers but we don't have the overhead of three (+two) additional interfaces. It would be great to get some opinions on this question so that we can make a decision on the architecture of our data model. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T68108: Store media information for files on Wikimedia Commons as structured data
Yann added a subscriber: Yann. TASK DETAIL https://phabricator.wikimedia.org/T68108 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yann Cc: Yann, intracer, Spinster, Orofarne, Filceolaire, MZMcBride, bzimport, wikibugs-l-list, TheDJ, zhuyifei1999, Meno25, DixonD, Bugreporter, RP88, Aklapper, Matanya, waldyrious, El_Grafo, Daniel_Mietchen, Jdforrester-WMF, GPHemsley, Bene, Legoktm, Nemo_bis, Lokal_Profil, Tobi_WMDE_SW, He7d3r, Petrb, Gilles, jayvdb, Kelson, MarkTraceur, Steinsplitter, JeroenDeDauw, Micru, revi, JanZerebecki, JeanFred, Ricordisamoa, Snowolf, Keegan, Rillke, Bawolff, Fabrice_Florin, Multichill, Liuxinyu970226, Ainali, Tgr, Lydia_Pintscher, jeremyb, Stryn, Ltrlg, daniel, Dereckson, JohnLewis, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T89597: Convert Template:Creator to Lua and use Wikidata
Yann added a subscriber: Yann. TASK DETAIL https://phabricator.wikimedia.org/T89597 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Yann Cc: Yann, Base, Matanya, Marsupium, Liuxinyu970226, Jheald, Ricordisamoa, Aklapper, Multichill, Izno, Wikidata-bugs, aude, Fabrice_Florin, Mbch331, Tgr ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T48521: Create a VisualEditor plugin tool to insert/edit references to Wikidata queries
MGChecker added a subscriber: MGChecker. Herald added a subscriber: Aklapper. TASK DETAIL https://phabricator.wikimedia.org/T48521 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: MGChecker Cc: Aklapper, MGChecker, Wikidata-bugs, Jdforrester-WMF, Tobi_WMDE_SW, Krinkle, Micru, Qgil, Lydia_Pintscher, Izno, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
JeroenDeDauw added a comment. It's generally good to design interfaces from the perspective of their users. This is done by looking at each user and determining what would be best for them, as opposed to trying to come up with an interface that suits all users (including those that do not exist yet). The existing provider interfaces serve their users well, and have optimal interface segregation (their users do not end up depending on stuff they do not need). If there is a new class of users, namely those where immutability is not desired, then creating a new interface is typically better than making the interface less ideal for both users and implementers. I think that looking at the number of interfaces one introduces is a very bad way of gauging complexity and maintenance cost. These come from the new functionality (the mutability) and the coupling caused by it. I'm a bit worried about the contract of the existing method though. It says no guarantee of mutability is provided, which means no guarantee of immutability is provided either. Users might use mutability they should not rely upon without this being noticed. After all, tests will pass, and the violation is not obvious, esp if the programmers are thinking about a specific concrete implementation where mutability is guaranteed. They have have to notice the docs in the interface. One way around this later concern is to have a dedicated interface for the case where users do not need mutability and implementers might not be able to provide it. In this interface the contract would be guaranteed lack of mutability. Users that would need mutability would use a different interface that does not, and this is key, derive from the other one. This interface would guarantee mutability. I'm not aware of which users you are trying to cater to, or what kind of implementations you have in mind. It depends on these what the best solutions are. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T106094: Add support for wikidata tag to iD (OpenStreetMap)
Yurik moved this task to Related on the Maps workboard. Herald added a subscriber: StudiesWorld. TASK DETAIL https://phabricator.wikimedia.org/T106094 WORKBOARD https://phabricator.wikimedia.org/project/board/1127/ EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mxn, Yurik Cc: StudiesWorld, Qgil, phabyogi, Lydia_Pintscher, Pigsonthewing, mxn, Aklapper, debt, Gehel, Lynhg, Izno, lxbarth, Wikidata-bugs, Malyacko, aude, Deskana, Yurik, scfc, Mbch331, Jay8g ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T89597: Convert Template:Creator to Lua and use Wikidata
zhuyifei1999 added a subscriber: zhuyifei1999. TASK DETAIL https://phabricator.wikimedia.org/T89597 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: zhuyifei1999 Cc: zhuyifei1999, Yann, Base, Matanya, Marsupium, Liuxinyu970226, Jheald, Ricordisamoa, Aklapper, Multichill, Izno, Wikidata-bugs, aude, Fabrice_Florin, Mbch331, Tgr ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
JeroenDeDauw added a comment. > It is not guaranteed that this method returns the original object. Weird contract, as there presumably is no guarantee there is such a thing as an original object. (the return value can be created on the fly) TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: JeroenDeDauw Cc: daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T126152: [RFC] Design of provider/holder interfaces in Wikibase's data model
Bene added a comment. > I'm a bit worried about the contract of the existing method though. I agree that this is not optimal for the reasons you pointed out. It would indeed be nicer if immutability could be provided. However, to achieve that we either have to make `TermList`, `StatementList` etc. immutable or we have to do a full object clone everytime we access the object which sounds quite expensive. > I'm not aware of which users you are trying to cater to, or what kind of > implementations you have in mind. It depends on these what the best solutions > are. The concrete users of these interfaces are the ones that currently use `FingerprintHolder`. We cannot longer bind terms to a fingerprint because not all entities have the combination a fingerprint provides (eg. the media type will only have labels and descriptions). Therefore, we need a way to tell a `LabelsProvider` that some label should change. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Bene Cc: daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Wikidata-bugs, aude, Mbch331 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
