Page MenuHomePhabricator

[Task] Discuss design of (De)Serializer interfaces
Closed, DeclinedPublic


Wikibase-DataModel-Serialization is designed so that all classes are package private except the two (De)Serializer factories. This contract is currently violated as repo type hints against some of these classes (fixed in

It seems we need to discuss if:


Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

Restricted Application removed a project: Patch-For-Review. · View Herald TranscriptApr 12 2016, 1:18 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

While I think it's valid to discuss this, it strikes me as something that ought to be low priority. There are much worse design issues to tend to elsewhere, and AFAIK this task is not a prerequisite for any user visible improvements. I have the impression this is being pushed due to personal interest rather than what makes sense for the team/project as a whole. If anyone disagrees with that, this is fine. I'm providing _my_ impression in the hope it is helpful.

I already commented on this at, amongst other places.

I would be interested how exactly this is blocking T118860. I assume this is not a hard blocker.

What "worse design issues"? What "personal" interest? Please qualify these statements.

This issue is not exclusive to (De)Serializers, the same happens in ValueFormatters, Parsers, Validators and some more: an interface that does not say anything but that a method with a name exists. It does not say anything about what goes in, and nothing about what comes out. This triggers type safety warnings in all kinds of tools. People see this, try to fix what they think is a design smell and either fail (and wasted their time) or work around the issue by simply type hinting against package private classes. This alone is, in my opinion, reason enough to discuss this. When the outcome of the discussion is that we keep the interfaces untouched, but we all have a better understanding of the situation, fine.

I don't understand your comment, what you are aiming for and what your suggestions are. But as I did not got a response for a month I suggested to use an other discussion format.

Lydia_Pintscher triaged this task as Medium priority.Apr 21 2016, 1:50 PM
thiemowmde closed this task as Declined.Feb 28 2018, 6:08 PM

I close this for now to reduce our backlog. This does not mean these unspecific "mixed" interfaces do not need discussion any more. But we can continue working on this code whenever the need arises.