thiemowmde added a comment.

My personal remarks:

  • Please find variable names that are more specific than fromId, toId(s), and propertyId.
    • fromId could be named childId.
    • toIds could be named parentIds.
    • propertyId could be named hasParentPropertyId or relationshipPropertyId.
    • The method itself could be named getClosestParentId then.
  • I'm not a fan of making to many parameters tables. Sure, this feels kind of natural. My investigation in T182147#3815415 also hinted at this possibility. However, the function will become complex and hard to use.
    • Multiple fromIds can be emulated by calling the function in a loop. Allowing fromIds to be a table does not save us much, I believe. We would need to traverse multiple trees upwards instead of one. Well, these trees might overlap, which allows us to cache and reuse intermediate results. But the same kind of caching can be done when the Lua function is called multiple times in a loop.
    • toIds should be a table, I believe. This allows to specify more than one possible end-condition. For example, I want to check if a biography is properly categorized as either "fictional" or "living person". "Fictional" and "living person" are exclusive and not subclasses of each other.
    • propertyIds can be a table. The algorithm that traverses the tree upwards would not become more complex because of this. Even with one propertyId given, each entity can have multiple. Allowing more than one propertyId would not change the fact that entities in this tree can have any number of parents. However: Because of the complexity that is often not needed I would not make this parameter a table.

My conclusion: I like the concept that returns an entity ID more.



To: hoo, thiemowmde
Cc: Lucas_Werkmeister_WMDE, thiemowmde, Lydia_Pintscher, daniel, Aklapper, aude, Ricordisamoa, Liuxinyu970226, hoo, Lahi, Gq86, GoranSMilovanovic, lisong, QZanden, LawExplorer, Wikidata-bugs, Mbch331
Wikidata-bugs mailing list

Reply via email to