thiemowmde added a comment. I vote for mutability. All provider interfaces (including the existing `FingerprintProvider` and possibly more) should guarantee they do nothing but returning what they have. If an implementation can not simply return an Object as it is but has to construct it whenever the getter is called, it should not use this interface. It should not be a requirement that a getter must do expensive cloning before returning anything. This should be a separate thing, which we just recently discussed, see https://github.com/wmde/WikibaseDataModel/pull/626. This also caused trouble in https://phabricator.wikimedia.org/tag/wikibase-datamodel-javascript/, see https://github.com/wmde/WikibaseDataModelJavaScript/pull/47 and much more patches there.
From my point of view this was one of the top reasons why we introduced "trivial" array wrappers like StatementList and so on. You can do … $fingerprint = $item->getFingerprint(); $fingerprint->setLabel( … ); … and be fine. This is not possible with arrays. A user calling a setter like in the example above should not be enforced to call an other setter. This feels like calling `setForReal()`. I find this confusing and can tell from experience that this is error-prone. - I consider calling `setFingerprint` a mistake in all cases. We do have some calls to this method in our code base because we had somewhat "broken" versions of https://phabricator.wikimedia.org/tag/wikibase-datamodel/ that returned a `new Fingerprint` in `getFingerprint`. All these setters should be removed. - I consider type hints against a `…Holder` interface a mistake and code smell when no setter is called. - We currently "misuse" `setStatements( new StatementsList() )` to remove all statements from an entity. This can easily be solved by introducing `StatementList::clear`. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: thiemowmde Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
