adrianheine added a comment. In https://phabricator.wikimedia.org/T126152#2021971, @daniel wrote:
> In https://phabricator.wikimedia.org/T126152#2021847, @adrianheine wrote: > > > Why would that be awkward? > > > For one thing, because the SiteLinkList (and ReferenceList, etc) would have > to know how to construct an entity, and which concrete type of entity to > construct, and how. I see no good way to do that. Yeah, well, that would be awkward. > Or, if you spread that over multiple levels, you end up with something like > > $statements = $entity->getStatementList(); > $statement = $statements->getStatement( $hash ); > $references = $statement->setReferenceList(); > $entity = $entity->setStatementList( > $statements->updateStatement( > $hash, > $statement->setReferenceList( > $references->addReference( $reference ) ) ) ); That's basically what I would suggest. We could add some delegation methods (`Item::getStatement( $hash )`), but it boils down to this. >> It's another item. Also, you don't need the old one afterwards. > > If you don't need the old one afterwards, why create a new one instead of > recycling the old one? Because it's much easier to reason about immutable data structures, and because immutable data structures can usually be implemented more efficiently. >> I think in ChangeOps it would not look worse. Also, what would be >> inefficient about that? We are neither doing a lot of changes in ChangeOps >> nor are we working a lot with the entities after having changed them, so >> both immediate and lazy manipulations should be efficient enough. > > Duplicating the entire data structure for every change of any part of it > seems rather wasteful. But you are right that it would be acceptable for > edits. It wouldn't be acceptable for filtering or augmenting a data structure > for output. That's where lazy manipulations could be used (`FilteredEntity(Entity, EntityFilter) implements Entity`). Quite difficult without generics. >> If I get this ticket right we'll probably have to rewrite a lot of code >> anyway, and we can think upfront about what it should look like afterwards. > > I don't see that, actually. We are adding interfaces that will mostly just > declare methods that already exist in the implementations. If we change > contracts, we'll have to check where that may cause problems, but this is a > far cry from changing the paradigm from "manipulate a data structure using > methods" to "construct derived data structure using pure functions". We will have to switch stuff from fingerprint to individual term manipulation. It's probably not that much, though. TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: adrianheine Cc: adrianheine, daniel, JeroenDeDauw, thiemowmde, Aklapper, Bene, StudiesWorld, Izno, Luke081515, Wikidata-bugs, aude, Mbch331 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
