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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to