Can BasicEntityIdParser not be used for the described usecase?

I also think that a general parser should be used and then an instanceof ItemId check be made,

You can not pass an instanceof check via composition.

The basic parser accepts properties. The only way to construct the parser needed for the use cases I described is as follows:

new DispatchingEntityIdParser( array(
    ItemId::PATTERN => function( $idSerialization ) {
        return new ItemId( $idSerialization );
    }
) );

This is not nice for two reasons: It's odd to have a "dispatching" parser delegating to a single function. And having that closure repeated several times in a code base is not nice.

If you can think of a nicer way to create a parser that accepts a single entity type only, please tell me.

So this new parser is for a use case where property ids can occur but should not be accepted?

Can you point to the code where this would be needed or provide a minimal example of why an EntityIdParser is needed rather than simply doing new ItemId( $serialization )? I'm quite hesitant to +2 this without being able to think of an example.

https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/lib/includes/formatters/EntityLabelUnitFormatter.php#L44 is designed to accept any EntityIdParser, which is a mistake in my opinion because we know we should not accept Property URIs as units. But @brightbyte argues that formatters can and should resolve labels for all entity types. I disagree.

The parser proposed in this pull request seems to be the easiest solution.

An other solution would be to rework EntityLabelUnitFormatter to not require an EntityIdParser but do the URI to ItemId parsing and validation itself. Is this better?

An other solution would be an EntityIdParser that can be told which constructor it should call. But I don't like the idea of passing a PHP class name around as a string.

An other solution would be to add this as a feature to the existing SuffixEntityIdParser. But I'm not sure how. Same problem as above.

See https://gerrit.wikimedia.org/r/#/c/219016/ for an alternative proposal.

This does not make this addition obsolete. I still think this can be useful, even if we are not going to use it right away.

@thiemowmde can this be closed for now?

Rebased.

Why should this be closed? Is there a problem why the suggested class can not be in this component?

I believe the use case for this is valid and it makes sense to have this parser. Needs updates of the version though. Will we do a 4.4 release for this?

In #551 (comment) I asked to add this to 4.3.0. Not sure why this was not possible.

Rebased again. Test added.

Any particular reason to release this as 4.4 today?

No, can wait some days. But thanks for asking.