daniel added a comment.
@Thiemo: I'm missing numbers for the Term, TermList, and TermFallback classes.
Did these slip through the cracks somehow?
TASK DETAIL
https://phabricator.wikimedia.org/T112893
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To:
thiemowmde added a comment.
Not sure how this happened. AliasGroupList, Fingerprint, and all Term classes
where missing. I updated my list above.
TASK DETAIL
https://phabricator.wikimedia.org/T112893
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To:
thiemowmde added a comment.
The task description talked about "data model objects", so I simply did the
same steps for all classes in the current
https://phabricator.wikimedia.org/tag/wikibase-datamodel/ 4.4.0 (dev).
TASK DETAIL
https://phabricator.wikimedia.org/T112893
EMAIL PREFERENCES
JeroenDeDauw added a comment.
Thanks for the overview Thiemo!
Note that you included some services, while this task is about value objects,
aggregates and entities.
TASK DETAIL
https://phabricator.wikimedia.org/T112893
EMAIL PREFERENCES
thiemowmde added a comment.
I did regex searches for `new Class(` instantiations as well as static
`Class::…(` calls in my local copy of the codebase, including all dependencies
(ValueView, DataModel, all DataValues, and so on). I did not included other
extensions like PropertySuggester or
Tobi_WMDE_SW added a subscriber: Tobi_WMDE_SW.
Tobi_WMDE_SW added a comment.
This should be extended to everything that is included in the Wikidata build
(e.g. serializers, etc..). We also need this for our tests (ideally separated).
TASK DETAIL
https://phabricator.wikimedia.org/T112893
JeroenDeDauw added a comment.
> Those aren't important for the current RFC
I was under the impression the proposal was to have interfaces for all value
objects (and presumably collections) in DataModel. If that is the case, we
should consider the cost of changes to all of them. If not, then
JeroenDeDauw added a comment.
Thanks for looking at this. Those findings are not surprising - such
construction ought to occur primarily in the data access layer and
deserialization code.
Any reason you did not include `EntityId` and derivatives?
Why did you exclude the tests? If I'm not
Bene added a comment.
In https://phabricator.wikimedia.org/T112893#1657772, @JeroenDeDauw wrote:
> Thanks for looking at this. Those findings are not surprising - such
> construction ought to occur primarily in the data access layer and
> deserialization code.
Indeed, our code seems to
daniel added a comment.
I think it's useful to have separate numbers for the tests, but I agree that we
should know those numbers too, since we need to fix these instances too.
TASK DETAIL
https://phabricator.wikimedia.org/T112893
EMAIL PREFERENCES
Bene added a comment.
Some statistics (test files excluded):
- `SnakObject`/`PropertyValueSnak` constructor calls (4 usages):
- repo: SnakFactory
- others: SnakDeserializer, DerivedPropertyValueSnak, LegacySnakDeserializer
- `SiteLink` constructor calls (19 usages):
- client: ClientHooks,
11 matches
Mail list logo