daniel added a comment. 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. > 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? > 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. > 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". TASK DETAIL https://phabricator.wikimedia.org/T126152 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel 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
