daniel added a comment. In https://phabricator.wikimedia.org/T118860#1813397, @mkroetzsch wrote:
> Structurally, this would work, but it seems like a very general solution with > a lot of overhead. Not sure that this pattern works well on PHP, where the > cost of creating additional objects is huge. I also wonder whether it really > is good to manage all those (very different!) types of "derived" information > in a uniform way. The need for this solution is driven by the fact that using separate implementation strategies for the different kinds of derived data was worked rather badly for us in the past to iterations of the serialization code. We ended up with a lot of inconsistencies and duplicate code. I do share the concern about performance. I think it is managable, but we should be careful about this. I think deferred deserialization is going to be key to that. > To pick just one example, consider the (article) URL of a SiteLink. To create > it, one needs to have access to the content of the sites table. In WDTK, we > encapsulate the sites table in an object (called Sites). To find out the URL > of a SiteLink, one has to call a method of the Sites object (called > getArticleUrl() or something), which takes a SiteLink as an input. This > design is simple and efficient, uses no additional memory for storing new > objects or values, and clearly locates the responsibility for computing this > information (the Sites table). But it requires the serialization and formatting code to depend on the lookup services, and have these lookup services injected. We have found that this is a bad thing, both in theory (representing all data in a dumb model before generating output was suggested by two external reviews) and in practice (where the cross-dependencies have kept us from splitting serialization code into a separate component for a long time). > In a single-site setting (like you have in PHP), there is only one sites > table, and you can access it statically, so the caller does not even need to > have a reference to a Sites object as in WDTK. I therefore don't see any > benefit in creating a role object for this simple task. It's just more > indirection, without any convenience for the software developer or any gain > in performance. Relying on global state like that for conveniance is what MediaWiki is doing all over the place, with horrible results for testability and modularity. Getting away from that tangle is one of my main priorities as a core architect. > There is only going to be a small number of different kinds of "derived data" > ever, and there is hardly any place where such data is used in a way that > does not need to understand its meaning (mainly for serialization). You always need to understand the meaning in order to use it. That's why roles are defined by interfaces. We are not passing around random blobs with random names. > I suppose that this proposal has nothing to do with JSON or RDF, but just to > be sure we are on the same page. Yes, this has nothing to do with JSON and RDF. Depending on the type of information, it would be represented in structurally different ways in the exported data structure. We have separate tickets for that. > The term "data model" is a bit over-used in our context -- maybe it would > make sense to indicate in this bug report that it is specific to the object > model used in the PHP implementation, and has no implications for other > implementations or export formats. You are right, this refers specifically to the PHP wikibase/data-model component. TASK DETAIL https://phabricator.wikimedia.org/T118860 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
