Visitor patterns for entity types and entity id types

[wetneb]

Arguably, the reason why #627 was allowed to happen in the first place is that the need for an update in DatamodelConverter was not flagged by the compiler when new entity types were introduced.

In functional programming languages this is normally solved by constructs like pattern matching where the compiler is able to detect the lack of exhaustiveness at compile time. In Java (or at least in this project) it seems to be achieved with Visitor patterns like SnakVisitor or ValueVisitor. As long as those interfaces get updated when a new child class is introduced, all the places which implement them then get compilation errors because the newly introduced methods are not implemented yet.

So I propose to introduce new interfaces:

• EntityDocumentVisitor (with methods for: ItemDocument, PropertyDocument, MediaInfoDocument, LexemeDocument, FormDocument, SenseDocument)
• EntityIdValueVisitor (with methods for: ItemIdValue, PropertyIdValue, MediaInfoIdValue, LexemeIdValue, FormIdValue, SenseIdValue)

[wetneb]

Actually it seems that those have been left out on purpose because entity types can be extended by Wikibase extensions:

Wikidata-Toolkit/wdtk-datamodel/src/main/java/org/wikidata/wdtk/datamodel/interfaces/ValueVisitor.java

Lines 23 to 35 in 4706ab9

	/**
	* A visitor for the various types of values in the datamodel. This should be
	* used to avoid any type casting or instanceof checks when processing values.
	* <p>
	* The visitor does not distinguish several types of {@link EntityIdValue},
	* since these are supposed to be extensible and therefore cannot be fixed in a
	* visitor interface.
	*
	* @author Markus Kroetzsch
	*
	* @param <T>
	* the return type of the visitor
	*/

Now the problem is: we still use instanceof on entity documents and entity id values at various places in WDTK's code, and we do not have a good way to keep track of those places when adding support for new types.

So I still think some visitor interface would be useful to add to all these places (to avoid instanceof and casting). Should we hide this interface from users so that they cannot rely on it? Or just make it clear in the documentation of the interface that its use should ideally be avoided because entities are extensible?